home *** CD-ROM | disk | FTP | other *** search
/ Simtel MSDOS - Coast to Coast / simteldosarchivecoasttocoast2.iso / citadel / ctdl338b.zip / UTIL3.MAN < prev    next >
Text File  |  1990-07-01  |  44KB  |  1,190 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7.  
  8.  
  9.  
  10.  
  11.  
  12.  
  13.  
  14.  
  15.                              UTILITIES MANUAL
  16.  
  17.                              CITADEL-86 V3.32
  18.  
  19.                             Copyright 1989, 1990
  20.  
  21.                                by Hue, Jr.
  22.  
  23.                           C-86 Test System Sysop
  24.  
  25.                                  90Jul01
  26.  
  27.  
  28.  
  29.  
  30.  
  31.  
  32.  
  33.  
  34.  
  35.  
  36.  
  37.  
  38.  
  39.  
  40.  
  41.  
  42.  
  43.  
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58.  
  59.  
  60.  
  61.  
  62.  
  63.  
  64.  
  65.  
  66.  
  67.  
  68.  
  69.  
  70.  
  71.  
  72.  
  73.  
  74.  
  75.  
  76.  
  77.                        TABLE OF CONTENTS
  78.  
  79.      History . . . . . . . . . . . . . . . . . . . . . . . . . . .  2
  80.      Introduction  . . . . . . . . . . . . . . . . . . . . . . . .  2
  81.      Clog.exe  . . . . . . . . . . . . . . . . . . . . . . . . . .  2
  82.      Clray.exe . . . . . . . . . . . . . . . . . . . . . . . . . .  3
  83.      Recover1.exe  . . . . . . . . . . . . . . . . . . . . . . . .  3
  84.      Expand.exe  . . . . . . . . . . . . . . . . . . . . . . . . .  4
  85.      Recover2.exe  . . . . . . . . . . . . . . . . . . . . . . . .  4
  86.      DataChng.exe  . . . . . . . . . . . . . . . . . . . . . . . .  5
  87.      Logedit.exe . . . . . . . . . . . . . . . . . . . . . . . . .  5
  88.      Popular.exe . . . . . . . . . . . . . . . . . . . . . . . . .  6
  89.      Culldir.exe . . . . . . . . . . . . . . . . . . . . . . . . .  6
  90.      Nodelist.exe  . . . . . . . . . . . . . . . . . . . . . . . .  7
  91.      MsgAdd.exe  . . . . . . . . . . . . . . . . . . . . . . . . .  7
  92.      MsgOut.exe  . . . . . . . . . . . . . . . . . . . . . . . . .  8
  93.      Clean.Exe . . . . . . . . . . . . . . . . . . . . . . . . . .  8
  94.      VirtAdmn.Exe  . . . . . . . . . . . . . . . . . . . . . . . .  9
  95.      RoutMail.Exe  . . . . . . . . . . . . . . . . . . . . . . . .  9
  96.      Screen.Exe  . . . . . . . . . . . . . . . . . . . . . . . . . 16
  97.      Ease.Exe  . . . . . . . . . . . . . . . . . . . . . . . . . . 16
  98.      Aff.Exe . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114.  
  115.  
  116.  
  117.  
  118.  
  119.  
  120.  
  121.  
  122.  
  123.  
  124.  
  125.  
  126.  
  127.  
  128.  
  129.  
  130.                                      -1-
  131.  
  132.  
  133.  
  134.  
  135.  
  136.  
  137.                               History
  138.  
  139.         The following is a chronological chart of the history of the updates
  140.      of the C-86 utilities.
  141.  
  142.      90May   HAW Aff; update RoutMail with +domains.
  143.      89Jun22 HAW Ease.
  144.      89Apr17 HAW Version 2 of LogEdit.
  145.      89Feb26 HAW Major Release update(3.16): Clean, RoutMail, VirtAdmn, Screen.
  146.      88Dec19 HAW MsgAdd, MsgOut; general cleanup.
  147.      88Jan04 HAW Culldir, Nodelist, and Loadshar detailed.  Lexpand deleted.
  148.      87Oct16 HAW V3 of Citadel-86 update.
  149.      86Apr08 HAW Version 2 of Popular detailed.
  150.      86Apr01 HAW Popular detailed.
  151.      85Aug25 HAW Ctdlchng expanded.
  152.      85Aug10 HAW Logedit detailed.
  153.      85May25 HAW Lexpand detailed.
  154.      85Apr25 HAW Reviewed for MS-DOS conversion.
  155.      85Feb18 HAW Recover2 detailed.
  156.      84Dec09 HAW Expand changed.
  157.      84Jun29 HAW Ctdlchng detailed.
  158.      84Jun28 HAW Expand detailed.
  159.      84Jun27 HAW Recover1 detailed.
  160.      84Jun26 HAW Clray detailed.
  161.      84Jun26 HAW Created. Clog detailed.
  162.  
  163.  
  164.                                Introduction
  165.  
  166.         Since the days of yore when we received Citadel from CUG (C User's
  167.      Group), several utilities of interest have been added to the package to
  168.      supplement the original two .com files that came with the package, to wit
  169.      CITADEL.COM and CONFIGUR.COM.  These come in two types: one, to provide
  170.      information about what's going on inside this monster which, due to
  171.      runtime space considerations, could not be gotten at; two, the ability to
  172.      change certain parameters which were either impossible to change once a
  173.      BBS was set up, or were, at the least, difficult to change.
  174.         The descriptions (such as they are) follow herein!
  175.  
  176.                                Clog.exe
  177.  
  178.         Clog provides access to the userlog for the Sysop.  To use it, the file
  179.      CTDLTABL.SYS (the one generated by CONFG and maintained by CTDL.EXE)
  180.      must be on the default disk, and so must be CTDLLOG.SYS.
  181.  
  182.         There are two ways of using Clog.  First, there is the simple call:
  183.  
  184.              D>CLOG
  185.  
  186.      This will print out on the console the list of users in the file as they
  187.      appear in the file.  The user of this program should be warned that
  188.      Citadel does not put new users into the userlog in sequential order.
  189.      Instead, they are hashed into the log.  Usually, first user to log into
  190.      the system ends up occupying the last position in the file!  In general,
  191.      users are sprinkled everywhere, so don't be alarmed if nothing shows up
  192.      right away.  Be patient.
  193.  
  194.  
  195.  
  196.                                     -2-
  197.  
  198.  
  199.  
  200.  
  201.  
  202.  
  203.         In any case, the list is printed out as follows.  First, the log
  204.      position will be printed out, which will always be in sequential order.
  205.      If nobody occupies that position, then Clog proceeds to the next log
  206.      position.  If somebody does occupy that position, then the name of that
  207.      person (or alias) will be printed out, followed by his/her status as
  208.      aide, expert/non-expert, screen width, and if they have net privileges 
  209.      the entry will be followed by a 'N'.
  210.  
  211.         The second way to use Clog is to give it arguments.  There are two
  212.      arguments currently available in the MS-DOS version.  The first is the
  213.      -P argument:
  214.  
  215.            D>CLOG -P
  216.  
  217.         This will cause the passwords to be listed along with the user's name.
  218.      This is useful if somebody forgets their password.  The second argument
  219.      is a user's name.  When a user's name appears on the command line, then
  220.      data for that account only will be shown.  You may use -P and a user's
  221.      name on the same command line.
  222.  
  223.         If, for some reason, the sysop wants a list to be put out to a file,
  224.      use the MS-DOS re-direction commands. If you want the list to be put out
  225.      to the file LOG.LST, the type
  226.  
  227.            D>CLOG >LOG.LST
  228.  
  229.      Naturally, the -P argument may still be used when re-directing output.
  230.  
  231.                                Clray.exe
  232.  
  233.         Clray.exe is another program used to view the userlog.  As before,
  234.      CTDLTABL.SYS must be on the default disk in the root directory, as must
  235.      CTDLLOG.SYS.  There are currently no arguments for Clray.
  236.  
  237.         Clray's purpose is to allow the sysop to see what order the users have
  238.      been calling in, starting with the last caller.  Along with the users
  239.      name, his/her aide status, column width, and expert status will be
  240.      printed, as in Clog.
  241.  
  242.         Simply call Clray to run it. Output redirection may be used as in CLOG.
  243.  
  244.                                Recover1.exe
  245.  
  246.         Occasionally, a room may be killed by accident by an aide.  Or worse,
  247.      a Village Idiot will break an aide's password, and then kill rooms which
  248.      the Sysop thinks has socially redeeming value.  It is at this point that
  249.      Recover1 may be of use.
  250.  
  251.         Recover1 may only be used if the following applies -- rooms have been
  252.      killed, but no rooms have been created.  If a room(s) has been created,
  253.      it may have overwritten the old data. Rooms which weren't overwritten can
  254.      still be saved of course.  If new rooms have been created, Recover2.exe
  255.      should be used.
  256.  
  257.  
  258.  
  259.  
  260.  
  261.  
  262.                                     -3-
  263.  
  264.  
  265.  
  266.  
  267.  
  268.  
  269.         To use Recover1, the system should be setup as normal. Simply call
  270.      Recover1.  It will read in CTDLTABL.SYS.  Then it will start looking at
  271.      the rooms as found in CTDLTABL.SYS.  When it finds evidence that a room
  272.      has been killed, it will printout on the screen the name of the room, and
  273.      ask the Sysop if s/he wants Recover1 to try to save the room.  If it
  274.      receives an upper or lower case Y, then it will do so.  Currently, there 
  275.      is no reason known why it shouldn't succeed.
  276.  
  277.         When finished it will announce so and replace CTDLTABL.SYS with the
  278.      updated version, and then leave.  However, hopefully you'll never need
  279.      this program.
  280.  
  281.                                Expand.exe
  282.  
  283.         Expand's purpose in life is to allow the sysop to expand the size of
  284.      his/her message file (CTDLMSG.SYS).  This makes it easy to move upwards
  285.      as one gets rich running Citadel for cold, hard cash and acquires better
  286.      and better equipment.
  287.  
  288.         Expand expects to the system to be in its normal setup.  Simply call
  289.      Expand without arguments.  Once it has loaded CTDLTABL.SYS, it will
  290.      display the current size of the message file, and then ask for the new
  291.      size.  Answer in Kbytes.  Now Expand will do it's job.  THIS IS A SLOW
  292.      PROCESS.  Be patient.  The program will be printing some stuff out that
  293.      might allow the sysop to figure out where the program is.
  294.  
  295.         Once the program is done, it will say so, and will also tell you that
  296.      there is no reason to reconfigure.  This is true.
  297.  
  298.                                Recover2.exe
  299.  
  300.         Recover2.exe is to be used in the extreme emergency of either A)
  301.      someone breaking an aide pwd and deleting rooms and then creating other
  302.      rooms, thus negating the utility of Recover1.exe, or B) the loss or
  303.      contamination of CTDLROOM.SYS.
  304.  
  305.         Use of Recover2.exe really should be avoided. The effects of
  306.      Recover2.exe are:
  307.  
  308.       * All <Z>Forgotten room lists are totally screwed up;
  309.       * Privacy status of rooms are lost and will have to be reset;
  310.       * Directory status of rooms are also lost and will have to be reset;
  311.       * Deleted messages will reappear in their rooms of origin;
  312.       * And so will inserted messages.
  313.       * Various other room privileges will be lost or screwed up.
  314.       * Everything will end up on the base floor.
  315.  
  316.         Recover2.exe works by scanning the message file. Each message has
  317.      associated with it its room of origin, so the program is fairly simple.
  318.  
  319.         However, it is also rather slow.
  320.  
  321.         The system should setup as normal.
  322.  
  323.  
  324.  
  325.  
  326.  
  327.  
  328.                                     -4-
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335.                                DataChng.exe
  336.  
  337.         The purpose of the DataChng.exe utility is to give the sysop the
  338.      ability to non-destructively several CTDLCNFG.SYS parameters.  The
  339.      relevant parameters are:
  340.  
  341.      #MAXROOMS
  342.      #MSG-SLOTS
  343.      #MAIL-SLOTS
  344.      #LOGSIZE
  345.      #SHARED-ROOMS
  346.      #NET-ARCH-ROOMS
  347.  
  348.         ALWAYS MAKE BACKUPS BEFORE USING THIS UTILITY!
  349.  
  350.         DataChng is a very crude and simple menu-driven program which exits
  351.      when an illegal selection is made from the menu.  On valid selections,
  352.      DataChng will ask for a new value, and then ATTEMPT to modify your
  353.      installation for the new value.  NOTE: As of this writing, the system
  354.      attempts all changes IN MEMORY.  If there is not enough RAM, then this
  355.      utility fails.  This should only happen for very large installations
  356.      ("large", in this case, does not refer to the message base; see
  357.      EXPAND.EXE for details on expanding your message base).  If this happens 
  358.      to you, then you should either attempt to hack the source for this
  359.      utility so that it uses temporary files (a tedious but simple procedure),
  360.      or entice someone into doing it for you (ibid).
  361.  
  362.         With the exception of the LOGSIZE parameter, all of the parameters may
  363.      either be shrunk or expanded.  LOGSIZE can only (currently) be expanded.
  364.  
  365.         Make sure to update your CTDLCNFG.SYS after using DataChng.exe!
  366.      However, you do NOT need to use CONFG.EXE after using DataChng.exe.
  367.  
  368.                                Logedit.exe
  369.  
  370.         LOGEDIT provides the ability to edit the user log offline.  LOGEDIT
  371.      will act in one of two ways, depending on the machine your system is
  372.      configured for.
  373.  
  374.         If the configuration is for a Zenith Z-100, LOGEDIT will be a simple,
  375.      very crude question and answer routine.  The system will ask for an
  376.      account to kill, which you answer by NUMBER (use CLOG to find the
  377.      numbers you need).  If you confirm the kill, the account is nuked.
  378.  
  379.         If the configuration is for a PClone, LOGEDIT will be a visually
  380.      oriented utility.  The account names will be listed; you may select
  381.      any by using the cursor keys.  Touching the DEL key will cause the
  382.      current account to be nuked.  Touching the carriage return will allow
  383.      you to view and edit the values of the account.  Touching the ESC key
  384.      will end LOGEDIT.
  385.  
  386.         The last action LOGEDIT performs is to digest the user log.  Please
  387.      do not interrupt it during this task.
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394.                                     -5-
  395.  
  396.  
  397.  
  398.  
  399.  
  400.  
  401.                                Popular.exe
  402.  
  403.         The POPULAR utility is a statistics-gathering utility, and, as such,
  404.      can be easily viewed as your basic feeping creaturism.  However, for those
  405.      of us who have somehow acquired that horrible taste for odd statistics
  406.      about how people use Citadel, it does serve some purpose.
  407.  
  408.         POPULAR gathers statistics about the Public rooms on a system.  These
  409.      statistics consist of simply calculating how many people have forgotten
  410.      each Public room on a system.  Yes, a rather odd statistic to gather, but
  411.      there it is.  Once it has finished processing the data, it displays the
  412.      results in tabular form, in (roughly) the following form:
  413.  
  414.      <room name>  <# of people who have forgotten this room> <% of total users>
  415.  
  416.         To use this utility, simply make sure your data files are in their
  417.      normal drives, and run this program.  The output of this program may be
  418.      redirected to a file via the MS-DOS ">" directive, although not all the
  419.      output will end up in the output file.  Unimportant output will continue
  420.      to go to the screen; the important data will end up in the file you
  421.      designated.
  422.  
  423.         There is one command line option available, "-M".  If this option is on
  424.      the command line to Popular, it will also scan the message file, counting
  425.      the number of messages that originated in each room and performing AML
  426.      calculations on a per room basis, and display those values for each public
  427.      room in the same tabular format.
  428.  
  429.         The rooms are displayed in descending order of how many people have
  430.      forgotten each room.
  431.  
  432.                                Culldir.exe
  433.  
  434.         The Culldir utility is to be used in conjunction with active directory
  435.      rooms.  Let's face it: while the FILEDIR.TXT/.RE option is real handy for
  436.      directory rooms, it's a real pain trying to keep FILEDIR.TXT culled of
  437.      files that no longer exist in the directory.  That's what Culldir is for.
  438.      It will go through a FILEDIR.TXT and delete all entries in it for which
  439.      files do not exist in the current directory.
  440.  
  441.         Usage is very simple.  Place yourself in the DOS directory that has
  442.      a FILEDIR.TXT with extra entries in it, and run Culldir.  It expects all
  443.      of the data that it will work on to be on the default drive, in the 
  444.      current directory.  If it doesn't find a FILEDIR.TXT, it will abort
  445.      operation.  Culldir is unique amongst the utilities in that it doesn't
  446.      need any of the normal Citadel-86 data files -- only a directory with
  447.      FILEDIR.TXT in it.
  448.  
  449.  
  450.  
  451.  
  452.  
  453.  
  454.  
  455.  
  456.  
  457.  
  458.  
  459.  
  460.                                     -6-
  461.  
  462.  
  463.  
  464.  
  465.  
  466.  
  467.                                Nodelist.exe
  468.  
  469.         Nodelist is intended to help you maintain, in some slight way, your
  470.      netlist.  There are two modes to Nodelist, with and without arguments.
  471.  
  472.         When you run Nodelist without arguments, its output to the screen will
  473.      consist of a listing of shared rooms.  Underneath each shared room will
  474.      be a list of the systems that you are sharing the room with, terminated
  475.      by a blank line.  You may use DOS' redirection ability ('>') to place the 
  476.      output in a file.
  477.  
  478.         Using arguments with Nodelist will, of course, alter its behavior.  
  479.      There are three arguments currently supported.  The first is "-n".  This
  480.      causes all the nodes on your nodelist that are not disabled to be listed.
  481.      The second argument is "-nd", and causes all nodes on your nodelist,
  482.      regardless of their status, to be listed.  The third argument is "-s",
  483.      which causes each system on your nodelist that you share rooms with to
  484.      be listed, along with the rooms you share.
  485.  
  486.                                 MsgAdd.exe
  487.  
  488.         MsgAdd.exe is utility for use with programs which act as gateways
  489.      between Citadel-compatible systems and other (foreign) networks.  Its
  490.      purpose is to allow the addition of messages to a Citadel-86 message
  491.      base.  The 'typical' system operator will rarely have a use for this 
  492.      utility.
  493.  
  494.         The command line format of MsgAdd is
  495.  
  496.       C>MsgAdd <node name> <file names>
  497.  
  498.         The first argument, node name, should be the name of a node on
  499.      your nodelist, typically (although not always) a node which has been
  500.      designated OtherNet.  The purpose of specifying a node name is to allow
  501.      correct routing address decisions to be made by MsgAdd, which will in
  502.      turn allow Citadel-86 to route messages from the foreign network to
  503.      other Citadel-86 systems.
  504.  
  505.         There should be at least one file name following the node name.  Each
  506.      file should contain at least one message from the foreign network in
  507.      C86Net message format (see NETHACK3.MAN for the complete specification).
  508.      Of all the fields that makes up a C86Net message, the following should
  509.      be filled in by the gateway program for each message:
  510.  
  511.         Author
  512.         Date
  513.         Name of Origin System - need not be 'node name' in the command line
  514.         Node ID of Origin System - a matter for some thought
  515.         Room for message - a MUST
  516.         Recipient iff msg is private mail
  517.         Message Text
  518.  
  519.         Attempting to add messages to rooms which are not shared with 'node
  520.      name' will result in warning messages, but the messages will be
  521.      inserted.  By formally sharing rooms with 'node name' you ensure that
  522.      the companion utility to MsgAdd, MsgOut, will pick up messages for the 
  523.      foreign net and speed them on their way.
  524.  
  525.  
  526.                                     -7-
  527.  
  528.  
  529.  
  530.  
  531.  
  532.  
  533.         There are two weaknesses in MsgAdd.  First, it does not do vortex
  534.      processing on the messages from the foreign network.  Second, it will
  535.      not add messages to Virtual Rooms.  Neither is inherent, but are simply
  536.      the result of a lazy programmer.
  537.  
  538.  
  539.                                 MsgOut.exe
  540.  
  541.         MsgOut is the reverse of the MsgAdd utility -- it will extract
  542.      messages from a Citadel-86 installation and write them to a file in
  543.      C86Net format, for later processing by a gateway program for insertion
  544.      into a foreign network.  The 'typical' system operator will have little 
  545.      to no use for this utility.
  546.  
  547.         Command line format for MsgOut is
  548.  
  549.       C>MsgOut <node name> <filename>
  550.  
  551.         'node name' is the name of a node on your nodelist for which you
  552.      wish to extract messages, while 'filename' is the file to place all
  553.      such messages in, no matter what room they came from.
  554.  
  555.         So, the question becomes, "What messages are extracted?"  The answer
  556.      is conceptually simple: Think of 'node name', despite being a designation
  557.      of a foreign (OtherNet) network, as just another C86Net system.  MsgOut
  558.      is then just like a normal network session.  All messages which would
  559.      have been sent to this system during a normal network session, both
  560.      shared rooms and netMail, will be written to 'filename' in C86Net format.
  561.  
  562.         The gateway program is then expected to digest 'filename' and pass
  563.      on those messages to the foreign network in the appropriate format.
  564.  
  565.         The only weakness in MsgOut is that it does not process Virtual Rooms.
  566.      As in MsgAdd, this weakness springs only from programmer laziness.
  567.  
  568.                                 Clean.Exe
  569.  
  570.         The Clean utility is an anti-ruggie utility.  Occasionally, a ruggie 
  571.      will gain access to your system and flood a favored room with messages of 
  572.      negative social value.  The most frustrating fact of this behavior is the 
  573.      knowledge that the good messages which were scrolled out of the room are 
  574.      still in the message, but no longer accessible.  This utility will make 
  575.      them available.
  576.  
  577.         Simply run Clean from the command line.  Clean will prompt for a room 
  578.      name, and then a list of names to 'clean' from the room (in case more 
  579.      than one ruggie has attacked).  Once you have typed in all names you wish 
  580.      cleansed from the room, Clean will scan through your entire message base 
  581.      for messages belonging to the named room.  Those messages written by 
  582.      users you designated will not be saved in the room any longer, while 
  583.      those by users you did not name will be saved, thus recovering 'scrolled' 
  584.      messages.  Those messages cleansed will no longer be accessible (unless 
  585.      you run Clean again on the same room and forget to name those users!).
  586.  
  587.         Perhaps sometime in the future this utility will be modified to allow 
  588.      cleansing an entire roombase of a user.
  589.  
  590.  
  591.  
  592.                                     -8-
  593.  
  594.  
  595.  
  596.                                 VirtAdmn.Exe
  597.  
  598.         This utility is the Virtual Room Administrator for Citadel-86, and as 
  599.      such is of interest only to backbones with heavy traffic.  The motivation 
  600.      and usefulness of VirtAdmn are explained in Section III.3.i of 
  601.      Network3.Man.
  602.  
  603.         VirtAdmn has two modes to it.  The first mode, interactive, is 
  604.      accessed by simply typing 'VirtAdmn' at the DOS command line.  It will 
  605.      place you in a primitive but adequate menu driven system which will let 
  606.      you add, delete, and modify virtual rooms from your system.
  607.  
  608.         The second mode is 'batch' mode.  This mode is used to allow VirtAdmn 
  609.      to delete 'virtual' messages from your system which are no longer needed, 
  610.      that is, which have already been delivered to all eligible systems.  We 
  611.      suggest this be run fairly often to keep your disks from running out of 
  612.      room, as some net rooms have fairly high traffic levels.  Consider using 
  613.      an external event to run Batch mode, possibly as part of an automated 
  614.      backup procedure.  Invocation of batch mode is by typing 'Virtadmn +batch'
  615.      at the command line.
  616.  
  617.         There is one more option which may be used with VirtAdmn, in both the 
  618.      interactive and batch modes, and that is the 'log' option.  When used, 
  619.      the results of the operation of VirtAdmn will be placed in your 
  620.      NETLOG.SYS file.  Simply add '+log' to the command line if you wish this 
  621.      to occur.
  622.  
  623.                                 RoutMail.Exe
  624.  
  625.        This section of the Utilities manual documents the program RoutMail.Exe.
  626.     RoutMail.Exe handles the administrative side of the C86Net RouteMail
  627.     feature.
  628.  
  629.        This is divided into two sections.  The first section is of interest to
  630.     any sysop wishing to participate in C86Net RouteMail.  The second section
  631.     is of additional interest to System Operators of backbone systems which
  632.     will be routing Mail for other systems.
  633.  
  634.        Please note that with the release of V3.32, which can support
  635.     secondary node lists (see NETWORK3.MAN) that are updated automatically,
  636.     most sysops' only use for RoutMail will be the +manual option.  Even the
  637.     major backbones (Domain Handlers) will have use, most of the time, only
  638.     for the '+domains' option (see below), along maybe with '+kill'.
  639.  
  640.     GLOSSARY
  641.  
  642.     HUB: A "HUB" node is any node which is willing to accept mail from one
  643.     node for delivery to another node.  This may optionally not include nodes
  644.     for which such traffic is very light and irregular, but will apply to
  645.     heavily used backbones such as Utica College, Chaos II, AARDVARK!, KAOS,
  646.     Test System, etc.
  647.  
  648.     PEON: A "PEON" node is a node which will carry very little or no netMail
  649.     from one node to another, but is more likely to simply send and receive
  650.     such netMail.
  651.  
  652.        Section 1: C86Net RouteMail for everyone.
  653.  
  654.        a) What is "RouteMail"?  RouteMail is a feature of Citadel-86's C86Net
  655.     which allows systems to send netMail to other systems without calling
  656.     those systems directly.
  657.  
  658.                                     -9-
  659.  
  660.  
  661.  
  662.  
  663.  
  664.  
  665.        b) How does it work internally?  Briefly, any system will know how to
  666.     send netMail to any system on its nodelist.  A), it'll call it directly,
  667.     or B) it will call some other node and ask it to pass the netMail on to
  668.     the target system.  In the case of B), it's not impossible, and in fact
  669.     fairly normal, for this intermediate system to call yet another system in
  670.     order to pass the netMail onwards, and this can continue, step by step,
  671.     until it reaches its destination.
  672.  
  673.        Three well-known systems of the net, for instance, are Chaos II in
  674.     Edmonton, Utica College (UCC) in Utica, NY, and Test System in the Twin
  675.     Cities of Minnesota.  Test System talks to the other two on a nightly
  676.     basis, but UCC and Chaos II rarely talk to each other.  Suppose Chaos II
  677.     wishes to send netMail to UCC.  During its nightly talk to Test System, it
  678.     would ask Test System to take this netMail and send it to UCC.  The next
  679.     time Test System talks to UCC, it would ask it to accept the Mail.  If the
  680.     target was not UCC, but some system "beyond" UCC, it would in turn try to
  681.     pass it on to that system, given that Test System knew that in order to
  682.     get to this system beyond UCC, it should go via UCC.  And etc.
  683.  
  684.        c) So why RoutMail.Exe?  To keep the main executables smaller.  Since
  685.     you can run RoutMail as a local door, and possibly as a remote door, this
  686.     should not cause problems or inconvenience.
  687.  
  688.      RUNNING ROUTMAIL
  689.        RoutMail can be run in one of two modes.  The first mode is called
  690.     'automatic' mode, and the second mode is called 'manual'.
  691.  
  692.        The purpose of automatic mode is to allow the sysop to update the
  693.     current netMail routes of C86Net on an automatic basis.  When RoutMail is
  694.     run in this mode it will read a textfile describing the current C86Net
  695.     configuration and update your nodelist with it, subject to some control
  696.     on your part.  Updating may include rerouting mail when a path to a node
  697.     becomes invalid and is replaced with another.
  698.  
  699.        The generic command line of RoutMail in automatic mode is this:
  700.  
  701.     C>RoutMail [options] <mapfile>
  702.  
  703.        That is, the program followed by zero or more 'options' selections
  704.     followed by the name of the map file to be digested by RoutMail.
  705.  
  706.        Your first question is probably, "What's this about a map??"  The map,
  707.     as noted, is a textfile describing the current C86Net.  The precise format
  708.     of the map is described in Section 2 (Advanced) of this file, and should
  709.     not be of concern to you unless you are a backbone likely to be involved
  710.     in the construction of the map, or enjoy abstruse details.  A current map
  711.     should be available at all times from your local backbone (if you are not
  712.     a backbone), or from one of the major backbones of the net (if you are a
  713.     backbone and want a more uptodate map), possibly Arcadia in Michigan.
  714.  
  715.        So now you'll want to know what these 'options' will do for you.
  716.     Options supported at the moment are
  717.  
  718.  
  719.  
  720.  
  721.  
  722.  
  723.  
  724.                                     -10-
  725.  
  726.  
  727.  
  728.  
  729.        "+add": allows RoutMail to add all unknown nodes found in the map to your
  730.     nodelist.  Such nodes will always be added as 1200 baud, non-local nodes
  731.     attached to net #15, under the assumption that most sysops will not be
  732.     using that net.  If you don't use this option, then nodes you are not
  733.     aware of on the net will not be added to your nodelist.  This will let you
  734.     keep your nodelist small.  In fact, there's little use (with the release
  735.     of V3.32) for this option; most routing responsibilities will be taken
  736.     over by the domain handling options (see below).
  737.  
  738.        "+kill": allows RoutMail to delete nodes from your nodelist which have
  739.     been designated in the map as "dead" nodes, that is, nodes which are
  740.     permanently off the network.  If you don't use this option, any node
  741.     designated as dead will not be affected on your nodelist.
  742.  
  743.        "+domains": this option lets the sysop add in to his primary node list
  744.     only those systems which are listed as Domain Handlers in his CtdlDmhd.Sys
  745.     file AND those systems via which, according to the routmail map which was
  746.     also present on the command line, you would use to get to those nodes.
  747.     This option is very useful to those systems which are already Domain
  748.     Handlers (since they are also usually backbones on the network, and
  749.     therefore need to know how to get to those other domain handlers).  We
  750.     recommend Domain Handler sysops run RoutMail with the +domains option
  751.     and the latest RoutMail map whenever they receive a new CtdlDmhd.Sys from
  752.     their distribution point.
  753.  
  754.        The second RoutMail mode is 'manual'.  Manual mode allows you to carry
  755.     out RoutMail and other network administration (as a convenience) on nodes.
  756.     The command line for using RoutMail.Exe in manual mode is
  757.  
  758.     C>RoutMail +manual
  759.  
  760.        Your options vis a vis RoutMail and nodes are as follows:
  761.  
  762.      o Accepting RouteMail from any given node (allows you to bar 'rogue'
  763.     Citadels from abusing your system)
  764.  
  765.      o Accepting RouteMail for any given node (allows you to not accept netMail
  766.     for any given system)
  767.  
  768.        Precise procedures for using RoutMail in manual mode should be
  769.     self-explanatory in the program prompts.
  770.  
  771.     Miscellanea about C86Net RouteMail itself
  772.     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  773.         This is not compatible with STadel mail routing.  However, this only 
  774.     applies to intermediate backbones; a target of a mail routing may be any 
  775.     node which supports C86Net normal mail - the Citadel-86 doing the routing 
  776.     will convert the mail to normal mail for the final relay to the target 
  777.     node.
  778.  
  779.         See NETWORK3.MAN on being a STadel gateway.
  780.  
  781.  
  782.     Section 2: Advanced - Map file structure
  783.     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  784.        This section describes the structure of the map file.  Since the map is
  785.     really all about systems, first we should specify how to put a system on
  786.     the map.  The jargon we'll use is 'system identifier', and the format is
  787.     this:
  788.  
  789.     <system node ID>:<system name> [@<baud>]
  790.                                     -11-
  791.  
  792.  
  793.  
  794.  
  795.  
  796.  
  797.        An example would be
  798.  
  799.     US 612 470 9635 : Test System
  800.  
  801.         and
  802.  
  803.     US 612 470 9635 : Test System @2400
  804.  
  805.         would also be valid.
  806.  
  807.        Note that while the nodeId given must be the system's node id, the node
  808.     name doesn't necessarily have to match what that system uses for a
  809.     nodename.  This alleviates problems with ridiculous names (such as TTWOL's
  810.     insistence on including its phone number in its nodename).
  811.  
  812.        When entering data into a mapfile, only data starting at the left most
  813.     column is significant.  Any line starting with one or more blanks is
  814.     considered a comment, not of use to RoutMail.
  815.  
  816.        The general structure of the map is this
  817.  
  818.     PEONS
  819.  
  820.     <description of all hub->peons relationships>
  821.  
  822.     HUBS
  823.  
  824.     <description of all hub->hubs relationships>
  825.  
  826.     CHANGES
  827.  
  828.     <description of all changes to individual nodes>
  829.  
  830.     DEAD
  831.  
  832.     <listing of systems that were on the net which are now off>
  833.  
  834.     COMMENTARY
  835.  
  836.     <talk about the netmap, if any>
  837.  
  838.  
  839.        The PEONS / HUBS / DEAD /etc. titles allow RoutMail to identify what the data
  840.     is all about.  We'll now go over the format of data for each section in
  841.     detail.
  842.  
  843.     PEONS section
  844.        This section identifies which "hubs" talk to which "peons" directly.
  845.     As noted in the glossary, a "hub" node is a node which is willing to carry
  846.     a lot of netMail from one node to another node, while "peons" are nodes
  847.     which do not act, usually, as intermediaries between different nodes.
  848.  
  849.  
  850.  
  851.  
  852.  
  853.  
  854.  
  855.  
  856.                                     -12-
  857.  
  858.  
  859.  
  860.  
  861.  
  862.  
  863.        This section's format is a series of records, each record separated
  864.     from the next by a blank line.  Each record is structured like this:
  865.  
  866.     <hub identifier>
  867.     <peon identifier>
  868.     <peon identifier>
  869.     <peon identifier>
  870.     ...
  871.  
  872.        Each record contains one hub node, the first in the list, and all of
  873.     the peon nodes which it will service.  No hub nodes should appear as peons
  874.     in these lists!  For instance, one possible record would be
  875.  
  876.     CA CA 403 433 2454 : Chaos II
  877.     CA CA 403 455 1701 : Quincunx
  878.     CA CA 403 426 1401 : Rock
  879.  
  880.     which would detail all the peons Chaos II services.  However, it would be
  881.     incorrect to add Test System to the bottom of that particular list,
  882.     because Test System will be serving as a hub.  The relationship between
  883.     Test System and Chaos II is described in the HUBS section, since they are
  884.     both hubs.  However, Test System would appear as the first member of
  885.     another list in the PEONS section, describing itself as a hub for systems
  886.     in the Twin Cities area.
  887.  
  888.        While no hub may appear in any of the lists as anything other than a
  889.     hub, and then only once, a peon may appear in more than one hub's listing.
  890.     This is due to the reality that more than one hub may exist in an area,
  891.     such as the UCC/KAOS tandem.  They don't overlap in their coverage, and so
  892.     provide the only (current) paths to certain nodes.
  893.  
  894.        Note that while a hub must be able to carry C86Net route mail in order
  895.     to be a hub, a Peon does not have to be similarly capable in order to be a
  896.     Peon, thus allowing the attachment of STadels, C-68Ks, and other such
  897.     normal Mail> capable systems to the netmap.  While such systems are
  898.     incapable of sending routed mail to other nodes, they may receive it.
  899.  
  900.     HUBS section
  901.        This section serves to detail the hub configuration.  The format is,
  902.     once again, a series of records, each a list of system identifiers
  903.     separated by blank lines.
  904.  
  905.        In this case, each record begins with a hub identifier, and is followed
  906.     by one or more hub identifiers.  The record serves as a definition of all
  907.     hubs which the first hub communicates directly with.  For instance, the
  908.     listing for Chaos II would be
  909.  
  910.     CA CA 403 433 2454 : Chaos II
  911.     US 612 470 9635 : Test System
  912.     [any other hubs Chaos II communicates directly with]
  913.  
  914.  
  915.  
  916.  
  917.  
  918.  
  919.  
  920.  
  921.  
  922.                                     -13-
  923.  
  924.  
  925.  
  926.  
  927.  
  928.  
  929.        Each hub in the C86Net should appear as a 'first' node once, and only
  930.     once, listing each hub it communicates directly with.  The implication is
  931.     a high level of redundancy occurs.  To complete our above example, it
  932.     would be necessary that somewhere in the HUBS section an entry of the form
  933.  
  934.     US 612 470 9635 : Test System
  935.     CA CA 403 433 2454 : Chaos II
  936.     [any other hubs Test System communicates directly with]
  937.  
  938.     also appear.  While the level of redundancy could undoubtedly be
  939.     reduced ... it ain't for the first version of RoutMail.  Sorry.
  940.  
  941.     CHANGES section
  942.        This section allows automatic changes of the nodelist by listing all 
  943.     nodes which have changed IDs or (more rarely) names.  The format in
  944.     this section differs from all others.
  945.  
  946.           <old id> : <new id> : <name> [@baud]
  947.  
  948.     is used for each node which has changed.
  949.  
  950.     DEAD section
  951.        The format of the DEAD section of nodes is simply a list of system
  952.     identifiers.
  953.  
  954.     COMMENTARY section
  955.        This section is functionally useless to RoutMail, and is ignored.  It 
  956.     can be used as a way to distribute news, instructions, or whatever strikes 
  957.     the fancy of the mapmaker.
  958.  
  959.     MAP EXAMPLE
  960.        The following is an example, based on our current situation, of a
  961.     possible net map.  Note that it's incomplete, since I don't know the
  962.     situation of even the Twin Cities in complete detail, much less anywhere
  963.     else.
  964.  
  965.     (* START OF EXAMPLE *)
  966.  
  967.      This file contains an example description of a C86Net topology similar to
  968.      an actual situation, involving Edmonton, Alberta, the Twin Cities of
  969.      Minnesota, Kalamazoo, Michgan, and Utica, NY.
  970.  
  971.     PEONS
  972.      This section covers Utica, NY.  Note that Jersey Devil, while a backbone
  973.      for the shared rooms, is not route mail compatible and is thus a peon,
  974.      while KAOS, much closer to UCC, is a hub itself for THE_LAND, an STadel,
  975.      and thus not on UCC's peon list.  Notice that since Swinger's is in the
  976.      area covered by both KAOS and UCC, it appears in both their lists.
  977.  
  978.     US 315 792 3187 : Utica College
  979.     US 315 735-2058 : Swinger's Den
  980.     US 609 893 2152 : Jersey Devil
  981.  
  982.  
  983.  
  984.  
  985.  
  986.  
  987.  
  988.                                     -14-
  989.  
  990.  
  991.  
  992.  
  993.  
  994.  
  995.      The land, being an STadel, is listed as a PEON, despite it being a main
  996.      backbone for the ST side of C86Net.
  997.  
  998.     US 315 735 0545 : KAOS
  999.     US 513 254 6811 : THE_LAND
  1000.     US 315 735-2058 : Swinger's Den
  1001.  
  1002.      This section covers Kalamazoo, Michigan.
  1003.  
  1004.     US 616 343 4136: Arcadia
  1005.     US 616 349 5887:The Beach
  1006.     US 616 381 3646:Secret Citadel
  1007.  
  1008.      This section is for the Twin Cities.
  1009.  
  1010.     US 612 470 9635 : Test System
  1011.     US 612 429 5001 : Backfence
  1012.     US (612) 431-4807 : Lumber Yard
  1013.     US 612-938-8580 : New Eden
  1014.     US 6124311107 : SuperComp III
  1015.  
  1016.      This section is for Edmonton.
  1017.  
  1018.     CA 403 433 2454 : Chaos II
  1019.     CA 403 455 1701 : QuinCunx
  1020.  
  1021.     HUBS
  1022.      Now for the hub descriptions.
  1023.  
  1024.     US 315 792 3187 : Utica College
  1025.     US 315 735 0545 : KAOS
  1026.     US 612 470 9635 : Test System
  1027.  
  1028.     US 315 735 0545 : KAOS
  1029.     US 315 792 3187 : Utica College
  1030.  
  1031.     US 612 470 9635 : Test System
  1032.     US 616 343 4136: Arcadia
  1033.     CA 403 433 2454 : Chaos II
  1034.  
  1035.     US 616 343 4136: Arcadia
  1036.     US 612 470 9635 : Test System
  1037.  
  1038.     CA 403 433 2454 : Chaos II
  1039.     US 612 470 9635 : Test System
  1040.  
  1041.     DEAD
  1042.      For completeness, we add one node in here, a node that recently went away
  1043.      in the Twin Cities.  Note we skipped right over the CHANGES section.
  1044.  
  1045.     US 612 425 0554 : Ivory Tower
  1046.  
  1047.     COMMENTARY
  1048.       And now for the news....
  1049.  
  1050.     (* END OF EXAMPLE *)
  1051.  
  1052.  
  1053.  
  1054.                                     -15-
  1055.  
  1056.  
  1057.  
  1058.                                 Screen.Exe
  1059.  
  1060.         Screen is a utility which allows easy modification of Citadel-86 
  1061.      sysConsole colors.  Usage is simple, just type 'SCREEN'.  You will then 
  1062.      be allowed to select colors for both the foreground and background as you 
  1063.      wish.  Once you are satisfied with your selection, ESC will terminate the 
  1064.      program.  If you ran Screen in your installation's main directory, Screen 
  1065.      will modify your CTDLTABL.SYS so that when you bring your system back up 
  1066.      the colors will be as you selected.  However, it will not modify your 
  1067.      CTDLCNFG.SYS file for you.  To help you do that, though, it will generate 
  1068.      a file named COLORS which will list your selections.  The reason you want 
  1069.      to modify your CTDLCNFG.SYS is in case you have a crash or something 
  1070.      which forces you to reconfigure.
  1071.  
  1072.         Screen will run equally well without a Citadel-86 installation, too.  
  1073.      It simply will not modify anything but the COLORS file it generates.
  1074.  
  1075.  
  1076.  
  1077.                               Ease.Exe
  1078.  
  1079.         Ease is the Citadel-86 installation and modification utility for the
  1080.      PC version of Citadel-86.  It has two tasks, already implied: installation,
  1081.      and modification (editing) your system.
  1082.  
  1083.         In order to run effectively, Ease requires the files Ease.Hlp (which
  1084.      should always accompany Ease.Lzh), Ease2.Hlp, Modems, and access to
  1085.      Citadel-86's CONFG.EXE program.
  1086.  
  1087.         Ease's abilities as an installation program should allow the creation
  1088.      of a minimal, non-netting system by both the novice and experienced
  1089.      sysops, including the creation of a useable CTDLCNFG.SYS.
  1090.  
  1091.         Ease's abilities as the Citadel-86 modification program are extensive.
  1092.      They include
  1093.  
  1094.       o Enabling netting
  1095.       o Editing all policy options
  1096.       o Editing all file locations
  1097.       o Modifying file sizes
  1098.       o Video modifications
  1099.       o #event editing
  1100.       o #door editing
  1101.       o etc
  1102.  
  1103.         The abilities of the Citadel-86 utilities DataChng, Expand, and
  1104.      Screen are completely contained in Ease, and Ease becomes the primary
  1105.      Citadel-86 utility as of its release.
  1106.  
  1107.  
  1108.                                 Aff.Exe
  1109.  
  1110.         Aff, which stands for Automatic File Forwarding, is a Citadel-86
  1111.      utility designed to simplify the job of automatically forwarding
  1112.      files from one system to another with only some initial sysop
  1113.      assistance.
  1114.  
  1115.  
  1116.  
  1117.  
  1118.  
  1119.  
  1120.                                     -16-
  1121.  
  1122.  
  1123.  
  1124.  
  1125.         The basic idea is there are certain files, updated from time to time,
  1126.      which should be sent to some set of systems after each update.
  1127.      (If this doesn't seem likely to you, then you probably have little
  1128.      use for this utility.)  By using the Aff utility in combination
  1129.      with the Citadel-86 #event to bring your system down periodically
  1130.      to run Aff, you can automate the process of sending said files to
  1131.      other systems when they are updated.
  1132.  
  1133.         Enough of the arm-waving.  In order for this to work, you have to
  1134.      tell Aff what you want sent, and where.  You do this via a file you
  1135.      construct named CTDLAFF.SYS, which will be located in your #NETAREA
  1136.      directory.  The structure of this file is:
  1137.  
  1138.      <filename>
  1139.      <system name> : 0
  1140.      <system name> : 0
  1141.      <system name> : 0
  1142.      ...
  1143.      <blank line>
  1144.      <filename>
  1145.      <system name> : 0
  1146.      <system name> : 0
  1147.      <system name> : 0
  1148.  
  1149.         The first line is the name of the file which will need to be sent
  1150.      each time it's updated.  There is one trick to this "filename" -- while
  1151.      you create the file in #NETAREA, you run the Aff utility from the same
  1152.      place you run Ctdl, and therefore Aff will look at the filename from
  1153.      the perspective of the normal Citadel directory, not #NETAREA.  So, if
  1154.      you use "relative" file names (like "..\hello.zip", etc), you'll have
  1155.      to be careful.  If you want to be smart, just use absolute file paths
  1156.      (like "C:\PRODUCT\STUFF.ZIP").
  1157.  
  1158.         All of the following lines up to the first blank line are the names
  1159.      of systems the file should be sent to.  Notice the format -- it's
  1160.      "<system name> : 0".  The reason for the ": 0" is that Citadel-86 will
  1161.      actually use CtdlAff.Sys to remember the last time it sent the file on
  1162.      to each system.  As the days pass, the "0" you should write in there
  1163.      will change to other numbers.  They represent the date stamp of the
  1164.      file last time you checked and sent it.  Don't mess with those numbers
  1165.      unless you know what you're doing (it's usually not necessary, anyways).
  1166.  
  1167.         You can update CtdlAff.Sys anytime you like, deleting systems,
  1168.      adding systems, adding whole new file forwarding specs.  However, the
  1169.      Aff utility itself cannot be run from within Citadel-86, only when the
  1170.      system is down.  For that reason, and if you don't already, you may
  1171.      want to consider putting together a #event of type external which will
  1172.      cause Aff to be run on an appropriate basis.  See INSTALL3.MAN for more
  1173.      information.
  1174.  
  1175.  
  1176.  
  1177.  
  1178.  
  1179.  
  1180.  
  1181.  
  1182.  
  1183.  
  1184.  
  1185.  
  1186.                                     -17-
  1187.  
  1188.  
  1189.  
  1190.