home *** CD-ROM | disk | FTP | other *** search
/ Simtel MSDOS - Coast to Coast / simteldosarchivecoasttocoast2.iso / citadel / k2ne603b.zip / CTDL_MAN.ZIP / OPER3.MAN < prev    next >
Text File  |  1988-02-25  |  63KB  |  1,784 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7.  
  8.  
  9.  
  10.  
  11.  
  12.  
  13.  
  14.  
  15.                           OPERATIONS MANUAL
  16.  
  17.                           CITADEL-86 V3.03
  18.  
  19.                              by Hue, Jr.
  20.  
  21.                        C-86 Test System Sysop
  22.  
  23.                                88Mar01
  24.  
  25.  
  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.      TABLE OF CONTENTS
  72.  
  73.  
  74.      I.   Introduction
  75.      II.  Help Files
  76.           II.  1. Location
  77.           II.  2. File Types
  78.           II.  3. Optional Customization
  79.           II.  4. Required Customization
  80.           II.  5. Optional Help Files
  81.           II.  6. Adding Help Files
  82.           II.  7. Delivered
  83.  
  84.      III. Sysop Privileged Functions
  85.           III. 1. Introduction
  86.           III. 2. Access
  87.           III. 3. Access Restrictions
  88.           III. 4. Sysop Capabilities
  89.           III. 5. Undocumented Sysop Menu Commands
  90.  
  91.      IV.  User Levels
  92.           IV.  1. Introduction
  93.           IV.  2. Normal Uses
  94.           IV.  3. Aide
  95.           IV.  4. Sysops
  96.  
  97.      V.   Rooms
  98.           V. I.  1. Room Archival
  99.           V. I.  2. Backbones
  100.           V. I.  3. Directory Status
  101.           V. I.  4. Innominate Status
  102.           V. I.  5. Lure Users
  103.           V. I.  6. Moderator
  104.           V. I.  7. Name Change
  105.           V. I.  8. Only Invitational
  106.           V. I.  9. Privacy Status
  107.           V. I. 10. Temporary Status
  108.           V. I. 11. Shared Status
  109.           V. I. 12. Upload/Download Status
  110.           V. I. 13. Withdraw Invitations
  111.           V. I. 14. Network Downloadable
  112.           V. II. Other Commands
  113.           V. III. Exceptions
  114.  
  115.  
  116.  
  117.  
  118.  
  119.  
  120.  
  121.  
  122.  
  123.  
  124.  
  125.  
  126.  
  127.  
  128.  
  129.  
  130.  
  131.  
  132.  
  133.  
  134.  
  135.  
  136.  
  137.      VI. Files - Upload/Download Capabilities
  138.          VI. 1. Origin
  139.          VI. 2. Creation
  140.          VI. 3. User Commands
  141.                 a. Contents Listing
  142.                 b. File Transfers
  143.                 c. <file spec>
  144.              4. Advanced Directory Options
  145.  
  146.      VII.  <O>ther Commands
  147.          VII. 1. General Purpose
  148.          VII. 2. Other Commands
  149.                  a. Deletion
  150.                  b. Outside Commands
  151.  
  152.      VIII. Miscellaneous
  153.           VIII. 1. Wha...?
  154.           VIII. 2. Chatty Questions
  155.           VIII. 3. Chat Capture
  156.           VIII. 4. ESCaping
  157.           VIII. 5. Sysop Autodial
  158.           VIII. 6. Denizens of the Status Bar
  159.           VIII. 7. Modem Disabling
  160.  
  161.     IX. Questions & Answers
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170.  
  171.  
  172.  
  173.  
  174.  
  175.  
  176.  
  177.  
  178.  
  179.  
  180.  
  181.  
  182.  
  183.  
  184.  
  185.  
  186.  
  187.  
  188.  
  189.  
  190.  
  191.  
  192.  
  193.  
  194.  
  195.  
  196.  
  197.  
  198.  
  199.  
  200.  
  201.  
  202.  
  203.      I.  INTRODUCTION
  204.  
  205.  
  206.  
  207.  
  208.  
  209.  
  210.  
  211.  
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226.  
  227.  
  228.  
  229.  
  230.  
  231.  
  232.  
  233.  
  234.  
  235.  
  236.  
  237.  
  238.  
  239.  
  240.  
  241.  
  242.  
  243.  
  244.  
  245.  
  246.  
  247.  
  248.  
  249.  
  250.  
  251.  
  252.  
  253.  
  254.  
  255.  
  256.  
  257.  
  258.  
  259.  
  260.  
  261.  
  262.                                     -1-
  263.  
  264.  
  265.  
  266.  
  267.  
  268.  
  269.      II.  HELP FILES
  270.  
  271.      II. 1. Location
  272.         The supporting help files of Citadel-86, which are simple text files,
  273.      should be located in the #HELPAREA drive and directory.  As explained in
  274.      the Installation Manual, you should copy these files to that directory
  275.      before operating your system, unless you do not plan to provide help to
  276.      the users of the system.
  277.  
  278.      II. 2. File types
  279.         There are three types of Help files, identifiable by their extensions.
  280.  
  281.         .BLB: These files contain miscellaneous messages and warnings for use
  282.                in certain set locations of Citadel-86.
  283.  
  284.         .MNU: These files contain menus that are normally printed out when the
  285.               user touches '?' while using Citadel-86.  Usually, these are just
  286.               lists of options.
  287.  
  288.         .HLP: These are general help files that are accessible through the
  289.               .Help <filename> command.  Generally, these files contain terse
  290.               instructions on the use of the system, including references to
  291.               other files that may be of help to the user.
  292.  
  293.      II. 3. Optional Customization
  294.         The Help files as delivered are of a generic nature, and any of them
  295.      may be modified using a text editor at the Sysop's option.  The .BLB
  296.      files are generally English descriptions of operations, and can be
  297.      modified for greater readability/useability with little danger of any
  298.      problems.
  299.  
  300.         On the other hand, the .MNU files should not be modified impulsively,
  301.      since they consist mostly of menu lists.
  302.  
  303.         The .HLP files are the best candidates for customization, since they
  304.      are English descriptions, and, for the most part, are not "hard-coded"
  305.      into Citadel-86; rather, they are usually referenced by the user after 
  306.      s/he finds a reference to them.
  307.  
  308.         All help files are formatted just like messages when they are
  309.      displayed to the user; therefore, you should be sure to follow the normal
  310.      Citadel formatting rules when rewriting Help files, except that you
  311.      needn't place a lone space on a blank line to enforce that blank line (a
  312.      difficult thing to do with many editors).
  313.  
  314.      II. 4. Required Customization
  315.         There are three files that you should customize for your installation
  316.      as soon as you feel you are prepared to.  They are
  317.  
  318.         HOURS.HLP: This file should contain the hours that your system is
  319.      available to users.
  320.  
  321.  
  322.  
  323.  
  324.  
  325.  
  326.  
  327.  
  328.                                     -2-
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335.         POLICY.HLP: This file should contain your general policy statement
  336.      regarding your system and its purpose.  The rules of your system could
  337.      also possibly appear here.
  338.  
  339.         NOCHAT.BLB: When you have Chat mode turned off on your system, this
  340.      file is printed to the users when they attempt to use the Chat command.
  341.  
  342.  
  343.         UNLOG.BLB: This file must be customized by Sysops running closed 
  344.      systems only.  When a user without a password attempts to log into
  345.      such a system, the system will print this file to the would-be user
  346.      if it exists.  If the file doesn't exist, then a hard-coded message
  347.      instructing the user to proceed to Mail> and leave a message for
  348.      Sysop.
  349.  
  350.  
  351.      II. 5. Optional Help Files
  352.         There are three Help files that do not need to be present during
  353.      Citadel-86's operation, but if they are will cause Citadel-86 to alter
  354.      its behavior slightly when a user is on the system.
  355.  
  356.         The first file is BANNER.BLB.  If this file is present in the #HELPAREA
  357.      directory when a user gains carrier, this file will be sent to the user. 
  358.      This allows large beginning banners to be used (remember that an unlogged
  359.      user always has a screen width of 40, so write your file accordingly). 
  360.      If the BANNER.BLB file is not present, then the #nodeTitle parameter of
  361.      CTDLCNFG.SYS will be sent to the user in its place.
  362.  
  363.         The second file is NOTICE.BLB.  If this file is present in #HELPAREA,
  364.      Citadel-86 will send it to the user upon a successful login.
  365.  
  366.         The third file is LONOTICE.BLB.  If this file is present in #HELPAREA,
  367.      Citadel-86 will send it to the user when the user executes any of the
  368.      Terminate commands before logging them out.
  369.  
  370.      II. 6. Adding Help Files
  371.         Through the use of the .Help command, users may access any file that
  372.      you place in the #HELPAREA that has a .HLP extension.  Therefore, if you
  373.      wish to extensively customize and extend the Citadel-86 Help system, you
  374.      should encounter few problems.
  375.  
  376.         When a user enters ".Help ?", however, the file HELPOPT.HLP will be
  377.      printed to them.  Therefore, you should take care to keep that file up
  378.      to date if you begin adding Help files.
  379.  
  380.  
  381.  
  382.  
  383.  
  384.  
  385.  
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394.                                     -3-
  395.  
  396.  
  397.  
  398.  
  399.  
  400.  
  401.      II. 7. Delivered
  402.         These are the Help files currently contained in RUNTIME.ARC, which
  403.      therefore you should have.  While it is always attempted to keep these
  404.      files up to date, we cannot guarantee that they are in keeping with the
  405.      release version of Citadel-86 that is in RUNTIME.ARC.
  406.  
  407.      .BLB files
  408.      BANNER.BLB   | Placeholder, printed to user on carrier detect.
  409.      ENTRY.BLB    | Printed to novice users entering a message.
  410.      NEWROOM.BLB  | Printed to novice users creating a new room.
  411.      NOCHAT.BLB   | Printed to users using the Chat command when inactive.
  412.      PASSWORD.BLB | Printed to novice users during new login process.
  413.      READDATE.BLB | Printed on entry of ".Read New ?" or Old or Reverse or ...
  414.      UNLOG.BLB    | Placeholder, for closed systems only (see X.4).
  415.      WCDOWN.BLB   | Printed to novice users when using .RW or .RX command.
  416.      WCUPLOAD.BLB | Printed to novice users when using .EF or .EXF or .EWF
  417.                   | command.
  418.      YMUPLOAD.BLB | Printed to novice users when using .EYF command.
  419.  
  420.      .MNU files
  421.      AIDE.MNU     | Printed when an Aide enters .Aide ?.
  422.      AIDEFLR.MNU  | Printed when an Aide enters ;Aide ?.
  423.      CONFG.MNU    | Printed when a user enters .Enter Configuration ?.
  424.      CTDLOPT.MNU  | Printed when a Sysop enters ? at the Privileged fn: prompt.
  425.      EDIT.MNU     | Printed when a user enters ? at the entry cmd: prompt.
  426.      ENTOPT.MNU   | Printed when a user enters .Enter ?.
  427.      FLOOR.MNU    | Printed when a user enters ;?.
  428.      MAINOPT.MNU  | Printed when a user enters ? or .? at a room prompt.
  429.      NETEDIT.MNU  | Printed when the Sysop enters ? at the Net Edit: prompt.
  430.      NETOPT.MNU   | Printed when the Sysop enters ? at the Net Cmd: prompt.
  431.      READOPT.MNU  | Printed when a user enters .Read ?.
  432.      ROOMA.MNU    | Printed when a remote Aide enters ? at the room edit:
  433.                   | prompt.
  434.      ROOMS.MNU    | Printed when a Sysop enters ? at the room edit: prompt.
  435.      SYSOPT.MNU   | Printed when a Sysop enters ? at the Other commands:
  436.                   | prompt.
  437.  
  438.      .HLP files
  439.      AIDE.HLP     | Aide help file.
  440.      AIDEFLR.HLP  | Aide help file for floor commands.
  441.      DOHELP.HLP   | Printed when user enters the Help command.
  442.      ENTER.HLP    | Help for the Enter commands.
  443.      EXTENDED.HLP | Explains usage of the "." commands.
  444.      FILES.HLP    | Upload/Download help.
  445.      FLOORS.HLP   | Floor help for the normal user.
  446.      FORGET.HLP   | Help on the ZForget room command.
  447.      GOTO.HLP     | Help on the Goto command.
  448.      HELD.HLP     | Help on Holding messages.
  449.      HELPOPT.HLP  | A directory of Help files.
  450.      HIDDEN.HLP   | Help on Hidden rooms.
  451.      HOURS.HLP    | Place holder, should contain your hours.
  452.      LOGINOUT.HLP | Help on Logging in and out of the system.
  453.      MAIL.HLP     | Help on Citadel-86's Mail system.
  454.      NET.HLP      | Help on C86Net.  This can be killed if you are not
  455.                   | networking.
  456.  
  457.  
  458.  
  459.  
  460.                                     -4-
  461.  
  462.  
  463.  
  464.  
  465.  
  466.  
  467.      POLICY.HLP   | Place holder, should contain your policy.
  468.      READ.HLP     | Help on using the Read commands.
  469.      SKIP.HLP     | Help on using the Skip command.
  470.      SUMMARY.HLP  | Complete summary of the "." and ";" commands.
  471.      YMODEM.HLP   | Help on YMODEM.
  472.  
  473.  
  474.      III. SYSOP PRIVILEGED FUNCTIONS
  475.  
  476.      III. 1. Introduction
  477.         In any system, there must be someone in charge if the system is to be
  478.      successful, and that person must have special abilities.  In Citadel-86,
  479.      anyone who has access to the system console may execute many of the Sysop
  480.      capabilities, and the root of all these evils (for necessary as Sysop as
  481.      powers are, they often lead to evil) is the Privileged Fn: menu (aka
  482.      the Sysop Menu).
  483.  
  484.      III. 2. Access
  485.         The Sysop Menu is accessed by typing a ^L (Control-L) at any room
  486.      prompt.
  487.  
  488.      III. 3. Access Restrictions
  489.         Access to the Sysop Menu is dependent on the location of the user at
  490.      the time of attempted use.
  491.  
  492.         If the user is at the System Console, then the user does not even have
  493.      to log in to use the Privileged Functions, once the System is in Console
  494.      mode.  While this may seem somewhat precarious to the prospective Sysop,
  495.      keep in mind that most installations do not normally run in public
  496.      locations.
  497.  
  498.         If the user is a remote user, then access is very restrictive.  First,
  499.      the system must be using the #sysPassword feature (see Section II.5.C of
  500.      INSTALL3.DOC) of Citadel-86.  Second, the user in question must be an
  501.      Aide of the system.  Finally, the user must possess the password
  502.      specified in the #sysPassword file, because the system will query the
  503.      Aide for the password when the ^L is pressed.
  504.  
  505.      III. 4. Sysop Capabilities
  506.         Due to the prejudices of the implementor, Citadel-86's Sysop
  507.      capabilities are neither variegated, overly powerful, or pretty; the
  508.      users of the system come before the Sysop.
  509.  
  510.         Be that as it may, the Sysop Menu is exactly what it sounds like: a
  511.      menu of choices which the Sysop may select from.  After each command
  512.      is executed, the Sysop is queried for another.
  513.  
  514.  
  515.  
  516.  
  517.  
  518.  
  519.  
  520.  
  521.  
  522.  
  523.  
  524.  
  525.  
  526.                                     -5-
  527.  
  528.  
  529.  
  530.  
  531.  
  532.  
  533.         This is the current official Sysop Menu.
  534.  
  535.      (CTDLOPT.MNU)
  536.  
  537.        <A>bort to main menu
  538.        <B>aud rate selection
  539.        <C>hat enable/suppress switch
  540.        <D>ebug switch
  541.        <E>cho to screen switch
  542.        <F>ile grab
  543.        <I>nformation
  544.        <K>ill account
  545.        <M>odem mode
  546.        <N>etworking commands
  547.        <O>ther commands
  548.        <P>rivilege switch (aide)
  549.        <R>einitialize modem
  550.        <S>et date
  551.       e<X>it to MS-DOS
  552.  
  553.         And here it is in detail.
  554.  
  555.      III. 4.a <A>bort
  556.         This command exits from the Sysop Menu, leaving you at the current
  557.      room prompt in CONSOLE mode.  If this command is equivalent to the
  558.      <M>odem mode command (X.4.i) if the user is a remote caller.
  559.  
  560.      III. 4.b <B>aud rate selection
  561.         This antiquated, obsolescent command allows you to set the baud rate
  562.      of the serial port to the value that you indicate.  This command has some
  563.      occasional usefulness in certain debug situations, so it still exists.
  564.  
  565.      III. 4.c <C>hat enable/disable
  566.         This command acts as a toggle for Chat enabled/disabled.  When Chat is
  567.      enabled, the System will display a 'C' somewhere on your Status bar, and
  568.      users using the <C>hat command will be able to page you.  When the toggle
  569.      is off, users using <C>hat will be greeted by your NOCHAT.BLB file (see
  570.      Section X, HELP FILES).  Aides using the .Aide Chat command can, however,
  571.      override this toggle.  A Sysop who really, truly wants privacy can use
  572.      the +nochat option on the command line to shut Aides out (see Section
  573.      II.9.a of INSTALL3.DOC).
  574.  
  575.      III. 4.d <D>ebug switch
  576.         This toggle command alternately turns debug code off and on.  Under
  577.      normal circumstances, this toggle should always be off.  There is no
  578.      telling what it will do from version to version, and in general will be of
  579.      little, if any, help in isolating problems with your installation; it is
  580.      more of a programming aide.
  581.  
  582.      III. 4.e <E>cho to screen
  583.         This toggle controls whether any output goes to the screen when the
  584.      system is in MODEM mode.  This option is, of course, inoperative while
  585.      the system is in CONSOLE mode.
  586.  
  587.  
  588.  
  589.  
  590.  
  591.  
  592.                                     -6-
  593.  
  594.  
  595.  
  596.  
  597.  
  598.  
  599.      III. 4.f <F>ile grab
  600.         This command allows the Sysop to "grab" text files that are anywhere
  601.      on his disk system into his Held Message buffer.  In essence, this gives
  602.      the Sysop an equivalent ability to a normal user's composing a message
  603.      offline and then uploading it.  The Sysop may compose a message using
  604.      his or her favorite editor, and then <F>ile grab it into the Held
  605.      Message Buffer.
  606.  
  607.         To be more precise, the <F>ile grab command only appends the text file
  608.      (or as much as it can digest) to the Held Message Buffer, thus allowing
  609.      construction of messages from several sources.  Furthermore, none of the
  610.      other contents of the Held Message are disturbed.  Therefore, you can
  611.      begin writing a message using Citadel-86, hold the message, <F>ile grab
  612.      something, and continue onwards.
  613.  
  614.      III. 4.g <I>nformation
  615.         This command provides information on the current version of Citadel-86
  616.      that you are running.  The information is provided in the following format:
  617.  
  618.  
  619.              Citadel-86 VM.mm
  620.              Net Version N.n
  621.              Commands version O.ooo
  622.              Ctdlcnfg.sys version Q
  623.  
  624.         "Citadel-86 VM.mm" is the same version that is printed on Carrier Detect
  625.      to users.  The "M" digit indicates the Major Change that Citadel-86 is at
  626.      ("1" was simply a version that worked under MS-DOS, "2" was the addition
  627.      of C86Net, "3" the addition of Floors).  The "mm" digits indicates changes
  628.      made to Citadel-86 that provides normal users with substantial new
  629.      capabilities.  Typically, "mm" does not change for new Sysop capabilities,
  630.      cosmetic changes, or the like; it's really nothing more than a gross
  631.      indicator of the version.
  632.  
  633.         "Net Version N.n" indicates the network capability of Citadel-86.  "N"
  634.      indicates any Major changes to the network (the first version of C86Net
  635.      did not have a number [boy, was it bad!], the second version was "0", and
  636.      the current is "1").  Due to the expandable nature of C86Net, "N" will
  637.      probably never change again.  "n" indicates Facility additions.  The
  638.      association of "n" to Facility addition is documented in the INCREM.* files
  639.      (which will be described shortly), and detailed in NETWORK3.DOC.
  640.  
  641.         "Commands version O.ooo" tells the real story behind what version you
  642.      are running.  "O" is the Enhancement version, and is incremented whenever
  643.      Citadel-86 is enhanced with a new command or appearance.  "ooo" is the Fix
  644.      version, and is incremented whenever a bug is fixed or another internal
  645.      change takes place.  "O.ooo" values are, again, documented in the INCREM.*
  646.      files.
  647.  
  648.         "Ctdlcnfg.sys version Q" tells what version of CTDLCNFG.SYS the system
  649.      is at.  Typically, this value is only incremented for Major Releases.
  650.  
  651.  
  652.  
  653.  
  654.  
  655.  
  656.  
  657.  
  658.                                     -7-
  659.  
  660.  
  661.  
  662.  
  663.  
  664.  
  665.         So what are these INCREM.* files?  These files, available on Test
  666.      System (ask the Sysop for access to them), and possibly other systems,
  667.      document the changes made to Citadel-86, albeit very tersely.  The format
  668.      of the documentation is:
  669.  
  670.      <version change>        <date>          <description>
  671.  
  672.         <version change> usually refers to the Commands version, although it
  673.      can refer to any of the version information in the <I>nformation command.
  674.      <date> is when the version change was written/released.  Description is
  675.      the terse description of what occurred to force the change in version;
  676.      when it is "???", it means that the Sysop was programming in his sleep
  677.      again and forgot what he did (here we take a deep breath ...).
  678.  
  679.         The INCREM.* files constitute the most reliable information on
  680.      upgrades to Citadel-86, short of asking Test System's Sysop himself.
  681.      Since he is a very grumpy person (born that way, you see), and is not
  682.      adverse to biting off the heads of anyone who comes near, it is better
  683.      to peruse these files once you have access to them.
  684.  
  685.      III. 4.h <K>ill Account
  686.         The time-honored function, Kill account, is accessed by typing K at
  687.      the Sysop Menu.  Please don't kill the account of the person currently
  688.      logged in.
  689.  
  690.      III. 4.i <M>odem mode
  691.         This command returns the system to MODEM mode.  If you have logged in
  692.      at the CONSOLE, it is NOT a good idea to use this command until you have 
  693.      logged out.
  694.  
  695.      III. 4.j <N>etworking commands
  696.         This option takes you to a submenu that is only available on systems
  697.      that are using the Network facilities (see II.5.d of INSTALL3.DOC and all
  698.      of NETWORK3.DOC).  Since NETWORK3.DOC should explain this menu in detail
  699.      (although perhaps not with the level of organization desired), we shan't
  700.      go any farther here.
  701.  
  702.      III. 4.k <O>ther commands
  703.         This option will deliver you to another submenu that is covered in
  704.      Section X, OTHER COMMANDS MENU.
  705.  
  706.      III. 4.l <P>rivileged switch
  707.         The creation of those drudges, Aides, takes place through this
  708.      command.  Anyone who is forced to become an Aide should also be forced
  709.      to read AIDE.HLP (conveniently written in pidgin Swahili), which details
  710.      most of the Aide capabilities.  As noted, Aides given the system password
  711.      will gain access to this menu.
  712.  
  713.      III. 4.m <R>einitialize modem
  714.         This option allows you to reinitialize the modem.
  715.  
  716.      III. 4.n <S>et date
  717.         This function lets you set the date of the system.
  718.  
  719.  
  720.  
  721.  
  722.  
  723.  
  724.                                     -8-
  725.  
  726.  
  727.  
  728.  
  729.  
  730.  
  731.      III. 4.o e<X>it to MS-DOS
  732.         Finally, this command should be used to take Citadel-86 down
  733.      gracefully. The current user is logged out if present, and the system 
  734.      will then attempt to deactivate itself.
  735.  
  736.      III. 5 Undocumented Sysop Menu Commands
  737.         There are always one or more undocumented commands floating around in
  738.      the Sysop Menu.  These are, without exception, debug commands for use by
  739.      the programmer(s) of Citadel-86, and are not guaranteed to exist from one
  740.      version to another of Citadel-86.  To expand even more upon this
  741.      frightening thought, the safety and integrity of your systems are not
  742.      guaranteed if you start screwing around with these options.
  743.  
  744.         So don't.
  745.  
  746.  
  747.      IV. USER LEVELS
  748.  
  749.      IV. 1 Intro to User Levels
  750.         Citadel-86 (and related systems) are often popular with users because
  751.      they do not have the superfluous user levels that many other types of BBS
  752.      software have.  We believe that this lets the user feel a little more free
  753.      with the system; the lack of direct control makes them willing to partici-
  754.      pate in the system earlier.
  755.  
  756.         However, this does not mean that Citadel-86 completely lacks in user
  757.      levels.  Citadel-86 uses the same 3-level hierarchy that came with the
  758.      original CP/M Citadel.  At the bottom is the normal users, with the usual
  759.      privileges of reading and writing.  Next comes the Aides, who are users
  760.      with certain caretaker powers.  Finally, the Sysops and remote sysops,
  761.      who can do a little more.
  762.  
  763.      IV. 2 Normal Users
  764.         Normal users are created, as you might guess, by simply logging in.
  765.      They may read, write, and upload to all rooms that they have access to.
  766.  
  767.      IV. 3 Aides
  768.         Aides are created using the <P>rivilege switch on the Sysop Menu (see
  769.      Section Y.4.l).  Aides are users who act as caretakers for the Sysop.
  770.      Their abilities and methods are summarized in AIDE.HLP and AIDEFLR.HLP
  771.      as well as here.  They have access to the private Aide> room.
  772.  
  773.      IV. 3.a Message Deletion
  774.         Aides may delete any message in the system with the exception of
  775.      messages in Mail>.  Messages which are deleted will be moved to the Aide
  776.      room, and will be preceded by a message from Citadel noting the name of
  777.      the Aide who performed the deletion.
  778.  
  779.         Messages in Mail> which are deleted by Aides (Aides only have access
  780.      to their own Mail> room) remain in Mail> and show up in the Aide> room.
  781.  
  782.         A message is deleted by <P>ausing the target message during printout,
  783.      and restarting message output by pressing 'D'.    The message will repeat,
  784.      and then the system will ask if you wish to Delete the message, Move the
  785.      message, or Abort the operation.  Selecting D will cause the message to
  786.      be deleted.
  787.  
  788.  
  789.  
  790.                                     -9-
  791.  
  792.  
  793.  
  794.  
  795.  
  796.  
  797.      IV. 3.b Moving Messages
  798.         Aides may move any message from its current room to another room.  The
  799.      moved message will also appear in the Aide> room, along with a message
  800.      regarding who moved the message.  Messages in Mail> may not be moved
  801.      successfully.
  802.  
  803.         A message is moved just like a message is deleted, by selecting 'M'
  804.      when the system asks if you wish to Delete, Move, or Abort the operation.
  805.      The Aide is then asked which room to move the message to.  If one or more
  806.      messages have been moved since the system was brought up, an empty
  807.      Carriage Return will put the message in the last room a message was moved
  808.      to.  The Aide does not need to type the entire name of the room to move
  809.      the message to; a partial name is sufficient, so long as it is unique
  810.      within the system.
  811.  
  812.         Moving a message to an auto-net room does not cause that message to
  813.      become a net message. Moving a message to an archived room does not cause
  814.      that message to be archived.  Moving a message to an anonymous room does
  815.      not cause that message to become anonymous.
  816.  
  817.  
  818.      IV. 3.c Room Elimination
  819.         Aides may delete any room in the system, with the exception of the
  820.      Mail>, Aide>, and #baseRoom rooms.  A message recording this fact will be
  821.      placed in the Aide> room.
  822.  
  823.         A room is killed by an Aide by being present in that room and execut-
  824.      ing the .Aide Kill command.
  825.  
  826.      IV. 3.d Empty Room Deletion
  827.         Aides may execute a command that deletes empty, temporary rooms from
  828.      the system.  A message will be left in the Aide> room listing the rooms
  829.      deleted by the command.
  830.  
  831.         The .Aide Delete command is used for this purpose.
  832.  
  833.      IV. 3.e Room Editing
  834.         Aides may edit the rooms of a system, with the exception of the Mail>,
  835.      Aide>, and #baseRoom rooms.  See Section Y ROOMS for more on these
  836.      actions.  To edit a room, either <A>ide or .Aide Edit room will allow you
  837.      to edit the room.  However, Aides may not set the full range of attributes
  838.      associated with a room; Section Y should cover this in full.
  839.  
  840.      IV. 3.f Message Insertion
  841.         An Aide may insert the last message deleted into a room.  The .Aide
  842.      Insert message command allows this.
  843.  
  844.      IV. 3.g Floor Creation
  845.         Aides may create floors at will.  New floors are placed in the first
  846.      empty floor slot, and there is no arbitrary limit on the number of floors
  847.      in a system.  Floor names may only be 19 characters in length, and each
  848.      must be unique within the system of floor names.  Floors may not be
  849.      created while in the Aide>, Mail>, or #baseRoom rooms, because the room
  850.      that a floor is created in will automatically become a room on that floor.
  851.  
  852.         ;Aide Create-floor creates a floor.
  853.  
  854.  
  855.  
  856.                                     -10-
  857.  
  858.  
  859.  
  860.  
  861.  
  862.  
  863.      IV. 3.h Room Moving
  864.         Aides may move rooms from one floor to another, with the exception of
  865.      the Aide>, Mail>, and #baseRoom rooms.  The Aide should be in a room that
  866.      is on the floor that the rooms should be moved to.  Once the command is
  867.      completed, a message will be placed in the Aide> room detailing what rooms
  868.      have been moved where.
  869.  
  870.         The command is ;Aide Move-rooms.  The system will prompt for the names
  871.      of rooms to be moved to the current floor.  Room names must be specified
  872.      in full.
  873.  
  874.      IV. 3.i Floor renaming
  875.         The ;Aide Rename-floor allows an Aide to rename a Floor.  The name must
  876.      be unique amongst the floors.
  877.  
  878.      IV. 3.j Floor Killing
  879.         Aides may delete Floors.  When this command is executed, the current
  880.      floor is assumed to be the target; the #baseFloor floor may not be killed.
  881.      The Aide will be asked if the rooms on the floor should be killed outright,
  882.      or placed on the #baseFloor.
  883.  
  884.         The command is ;Aide Kill-floor.
  885.  
  886.      IV. 3.k Aide Command Summary
  887.  
  888.       .Aide Delete empty rooms
  889.       .Aide Edit current room
  890.       .Aide Insert pulled message
  891.       .Aide Kill current room
  892.  
  893.       ;Aide Create floor
  894.       ;Aide Delete empty floors
  895.       ;Aide Kill floor
  896.       ;Aide Move rooms to floor
  897.       ;Aide Rename floor
  898.  
  899.      IV. 3.l Possible extra privileges
  900.         Depending on the configuration of the system, Aides may have additional
  901.      privileges that the users do not.
  902.  
  903.         First, Aides may be the only users able to create new rooms.
  904.  
  905.         Second, Aides may be the only users able to use the Mail> room.
  906.  
  907.      IV. 4 Sysops
  908.         There are potentially two different Sysops.
  909.  
  910.         First, and always, there is the person at the system console.  Certain
  911.      Sysop abilities can be executed without being logged in, notably the
  912.      Sysop Menu functions (Section Y: SYSOP PRIVILEGED FUNCTIONS); the rest,
  913.      what few are there, require that the Sysop be logged in.
  914.  
  915.  
  916.  
  917.  
  918.  
  919.  
  920.  
  921.  
  922.                                     -11-
  923.  
  924.  
  925.  
  926.  
  927.  
  928.  
  929.         Second, when the #sysPassword parameter is in use, an Aide in
  930.      possession of the system password may use it to become a remote Sysop.
  931.      A Remote Sysop has most of the capabilities of an Aide at the System
  932.      Console, including access to the entire Sysop Menu, and complete control
  933.      of room editing (see Section Y: ROOMS).
  934.  
  935.         The only other options available to a Sysop that are not available to
  936.      Aides, outside of the Sysop Menu, follow.
  937.  
  938.      IV. 4.a Message Journaling
  939.         Sysops may select individual messages to be placed in normal MS-DOS
  940.      text files for future reference; this is called Journaling. This command
  941.      is executed by <P>ausing the target message during output, and restarting
  942.      it with a 'J'.  The system will then ask for the name of a file to place
  943.      the text of the message in.  If the Journaling command has been used
  944.      before, then an empty Carriage Return will cause the message to be
  945.      appended to the last file specified.
  946.  
  947.      IV. 4.b Directory Journaling
  948.         Sysops may Journal the directories of directory rooms.  The process is
  949.      the same as Message Journaling.
  950.                                              
  951.  
  952.      V. ROOMS
  953.  
  954.      V. I Room Attributes
  955.         Rooms are the basic foundation of the Citadel-86 system, acting as the
  956.      main organizer and container of the messages of the system; the collection
  957.      of rooms of a Citadel-86 essentially constitutes the character of the
  958.      system.
  959.  
  960.         Rooms on a Citadel-86 can have a number of attributes associated with
  961.      them, each working independently, and most do not interfere with each
  962.      other's usefulness.  With the exception of the first three rooms, there
  963.      should not be any restriction on what rooms can have what attributes.  So
  964.      let's discuss what a room can do, besides contain messages.
  965.  
  966.         In order to set any of these attributes, the room must be edited by
  967.      an Aide.  If the Aide is accessing the system remotely and has not used
  968.      the Remote Sysop Password, then the Aide's powers are restricted, while
  969.      an Aide at the system console or a Remote Sysop's powers are not
  970.      restricted.  In the following discussion, the option letter used to
  971.      activate or deactivate an attribute is given along with the explanation
  972.      of the feature.
  973.  
  974.      V. I. 1 Room Archival
  975.         <A>rchive status, a Sysop-only option, allows the Sysop to save all the
  976.      messages that are entered into a room, whether locally or via the network,
  977.      to a normal MS-DOS text file (formatted for a 80 column user).  When this
  978.      option is activated, the Sysop is asked for a filename that will contain
  979.      the saved messages.  This file may reside anywhere on the system.  An
  980.      initial archive of the room will take place, and thereafter all messages
  981.      entered into this room will be saved to the file upon entry.
  982.  
  983.  
  984.  
  985.  
  986.  
  987.  
  988.                                     -12-
  989.  
  990.  
  991.  
  992.  
  993.  
  994.  
  995.         Messages that are deleted from the room will NOT be deleted from the
  996.      archive file, and, similarly, messages that were entered in another room
  997.      and subsequently moved to the archive room will not be saved to the
  998.      archive file, except on initial archive.
  999.  
  1000.      V. I. 1.a Room Archival: Advanced Usage
  1001.         Typically, the name (and/or location) of the archive file should be
  1002.      changed by editing the room.  However, the impatient or secretive Sysop
  1003.      can change the name of the archive file in another way.  The names of the
  1004.      files used for room archival are kept in the text file CTDLARCH.SYS, which
  1005.      resides in the #ROOMAREA directory.  CTDLARCH.SYS is generated and
  1006.      maintained by CTDL.EXE, and should not be disturbed while CTDL.EXE is in
  1007.      operation (i.e., through <O>utside commands).  When CTDL.EXE is down,
  1008.      however, the Sysop may edit CTDLARCH.SYS to his liking.  Adding entries
  1009.      will be ineffective; changing entries works.  The format is
  1010.  
  1011.         <room slot number> <file name>
  1012.  
  1013.      The room slot number should not be changed.  The filename, of course, may
  1014.      be changed.
  1015.  
  1016.         Do not delete entries from this file, either.
  1017.  
  1018.      V. I. 2 Backbones
  1019.         Please see NETWORK3.DOC for the use of the <B>ackbone status option.
  1020.      This is a Sysop only option.
  1021.  
  1022.      V. I. 3 Directory status
  1023.         Please see Section Y.y for details on the upload/download capabilities
  1024.      of Citadel-86 that are made available through the <D>irectory status
  1025.      option of room editing, a Sysop only option.
  1026.  
  1027.      V. I. 4 Innominate status
  1028.         The <I>nnominate option allows any aide to designate a room to be an
  1029.      Anonymous room.  A room which has been designated Innominate behaves
  1030.      differently from a normal room in the following ways:
  1031.  
  1032.        o All messages entered in it locally are saved with the author's name
  1033.      being "****".  Editing a room back to normal ("authored") status does NOT
  1034.      restore those messages' authors.
  1035.  
  1036.        o Echo to screen is suppressed during message entry in Innominate rooms.
  1037.  
  1038.      V. I. 5 Lure users
  1039.         Any aide may use the <L>ure users option to, in effect, invite any
  1040.      user into any room except the Aide room.  The user(s) specified are given
  1041.      access to the room being edited.  If they already had access, no change
  1042.      is made to their status.
  1043.  
  1044.      V. I. 6 Moderator
  1045.         Any room may have one moderator attached to it.  A moderator is
  1046.      effectively an Aide for that single room, able to edit the room and delete
  1047.      messages.  The user specified does not need any special privileges.  Any
  1048.      Aide may change the moderator setting for a room via the <M>oderator
  1049.      command.
  1050.  
  1051.  
  1052.  
  1053.  
  1054.                                     -13-
  1055.  
  1056.  
  1057.  
  1058.  
  1059.  
  1060.      V. I. 7 Name Change
  1061.         Any Aide may change the name of a room via the <N>ame change command
  1062.      while editing a room.  There are three constraints on the name of a room.
  1063.  
  1064.        o It must be 19 characters or less long.  A zero length name IS viable,
  1065.      but be aware that if the room ever becomes empty, there is no way to
  1066.      access that room.
  1067.  
  1068.        o It must be unique within the system.
  1069.  
  1070.        o It may have no more than one space in a row.
  1071.  
  1072.      V. I. 8 Only Invitational
  1073.         A room can be set to one of three status settings insofar that users
  1074.      are allowed access to it.  A room may be Public, in which case all users
  1075.      have access to the room.  If a room is Private, then all users that know
  1076.      the name of the room may gain access to the room simply by typing ".Goto
  1077.      FULLROOMNAME". (See Section X.I.9 for the Public/Private settings.)
  1078.      Or a room may be Invitational.  Users can only gain access to such a room
  1079.      by being invited (i.e., <L>ured -- see Section X.I.5).  Even if they know
  1080.      what the name of the room is, they cannot successfully .Goto it.
  1081.  
  1082.         A room can be either Public, Private, or Invitational, but not any
  1083.      combination.  It would perhaps be more logical to combine the <O>nly
  1084.      Invitational command (this one), with the following command, <P>rivacy
  1085.      status.
  1086.  
  1087.      V. I. 9 Privacy Status
  1088.         Any Aide may set the <P>rivacy status of a room.  Section X.I.8
  1089.      provides an adequate explanation of privacy and rooms.
  1090.  
  1091.      V. I. 10 Temporary Status
  1092.         Any Aide may set the <T>emporary status of a room.  Any room may be
  1093.      either Temporary or Permanent.  A Temporary room is a room that may be
  1094.      deleted by any of three events when it becomes empty (i.e., no messages
  1095.      in the room):
  1096.  
  1097.        o An Aide executes a .Aide Delete empty rooms command;
  1098.  
  1099.        o The number of rooms in use in the system reaches #MAXROOMS and another
  1100.      room is created;
  1101.  
  1102.        o The system is reconfigured (see Section ??? [installation manual] on
  1103.      the CONFG program).
  1104.  
  1105.         A Permanent room may only be deleted by a specific .Aide Kill Room
  1106.      command.
  1107.  
  1108.         All Directory rooms are Permanent.  Otherwise, if Permanent status is
  1109.      desired for any room, it must be explicitly set by use of the <T>emporary
  1110.      status command.
  1111.  
  1112.  
  1113.  
  1114.  
  1115.  
  1116.  
  1117.  
  1118.  
  1119.  
  1120.                                     -14-
  1121.  
  1122.  
  1123.  
  1124.  
  1125.  
  1126.  
  1127.      V. I. 11 Shared status
  1128.         The Sysop may use the <S>hared status command to affect the current
  1129.      room's Network status, including which systems to network with and which
  1130.      should not be networked with.  Please consult NETWORK3.DOC for more
  1131.      details.
  1132.  
  1133.      V. I. 12 Upload/Download status
  1134.         The Sysop may use the <U>/D status command to change the upload/down-
  1135.      load status of a directory room.  See Section Y.y for more details on 
  1136.      this command.
  1137.  
  1138.      V. I. 13 Withdraw Invitations
  1139.         On occasion, users need to be evicted from a room.  The <W>ithdraw
  1140.      Invitations command allows any Aide to evict users from a room.  This
  1141.      command is certainly not useful for Public rooms, and not entirely
  1142.      effective for private rooms, but can be very useful for Invitational
  1143.      rooms.
  1144.  
  1145.      V. I. 14 Network Downloadable
  1146.         The Sysop may use the <Z> command to designate whether or not a
  1147.      directory room may be accessed via the network for download purposes.
  1148.      See Section Y.y for more details on this command.
  1149.  
  1150.      V. II Other room editing commands
  1151.         There are two other commands that an Aide may use while editing rooms.
  1152.      The first is <V>alues, which gives the current positive attributes of the
  1153.      room.  The second is e<X>it editing, for exiting from the editing process.
  1154.      When substantive changes have been made to a room, a message is left in
  1155.      the Aide> room detailing the changes made.
  1156.  
  1157.      V. III Three exceptions
  1158.         Three rooms cannot be modified through editing (or any other process),
  1159.      and these rooms are
  1160.  
  1161.        o #baseRoom>.  This room is always a Public, Permanent room.
  1162.  
  1163.        o Mail>.  This room is a very special room, but essentially boils down
  1164.      to Public, Permanent, with some Shared capabilities.
  1165.  
  1166.        o Aide>.  This room is a Permanent, Invitational room, with Invitations
  1167.      automatically issued to Aides.
  1168.  
  1169.      VI. UPLOAD/DOWNLOAD CAPABILITIES
  1170.  
  1171.      VI. I Origin
  1172.         According to what rumors we have gathered from Seattle, the origin of
  1173.      Citadel, the original Citadel installations did not have any upload/down-
  1174.      load facilities; they were pure message systems.  Reportedly, "directory
  1175.      rooms" were kludged in at a later time as an afterthought.
  1176.  
  1177.  
  1178.  
  1179.  
  1180.  
  1181.  
  1182.  
  1183.  
  1184.  
  1185.  
  1186.                                     -15-
  1187.  
  1188.  
  1189.  
  1190.  
  1191.  
  1192.  
  1193.         They must be one of the more successful kludges in history.  Directory
  1194.      rooms, which serve as "windows" to the host operating system's file system
  1195.      in Citadel-86, have proven to be extremely useful constructs, allowing
  1196.      access to specified parts of MS-DOS's file system while not disrupting
  1197.      Citadel's structure with such excess baggage as "file sections".  The room
  1198.      structure allows easy division of files into their subject areas, and this
  1199.      integration into the room structure offers the additional, and very
  1200.      useful plus, of allowing conversation relevant to those files to coexist
  1201.      within easy reach of the user.  Compare this to, say, Fido or RBBS, which
  1202.      force you to go from a file section to a message section in order to
  1203.      discuss a file, and the advantages of Citadel (at least to this author)
  1204.      become obvious.
  1205.  
  1206.  
  1207.      VI. 2 Creation
  1208.         A directory room is created by editing an existing room to directory
  1209.      status.  This is an operation that only a Sysop can do, using the .Aide
  1210.      Edit command.  Once at the room edit prompt, the Sysop should select the
  1211.      <D>irectory option.
  1212.  
  1213.         Citadel-86 will ask if you wish to activate a directory for this room,
  1214.      and you should of course answer yes.  It will then ask for the name of a
  1215.      directory to associate with this directory room.  You should answer with
  1216.      the name of a normal MS-DOS directory.  You may specify a drive, and the
  1217.      directory may be a subdirectory of the current directory, or it may be
  1218.      an absolute specification; there is no limit.  If you simply hit a
  1219.      Carriage Return, Citadel-86 will assume that you mean the current
  1220.      directory on the current drive.
  1221.  
  1222.         If you specify a directory that does not exist, Citadel-86 will ask
  1223.      you if it should be created, and if you answer affirmatively, it will
  1224.      be created.  Otherwise, you will be asked again.
  1225.  
  1226.         Finally, the system will ask if the room will accept uploads and allow
  1227.      downloads (these options can be accessed while editing rooms separately
  1228.      by selecting the <U>/D option).  This gives you some control over the
  1229.      behavior of the directory room.  When either of these options are "off",
  1230.      only a sysop can upload or download or read the directory, depending on
  1231.      the option.
  1232.  
  1233.         A file room is identified by the character at the end of the room name.
  1234.      Normal rooms have a ">".  Normal directory rooms have a "]", while
  1235.      directory rooms which are also shared with other systems (which has no
  1236.      meaning insofar as the directory goes) have a ":".
  1237.  
  1238.      VI. 3 User commands
  1239.         The user is provided with two sets of commands for accessing the
  1240.      directory of a room.
  1241.  
  1242.      VI. 3.i Content listing
  1243.         When a listing of the files in a room is requested, only the visible
  1244.      files are listed.  Hidden files and subdirectories in the directory are
  1245.      not listed.
  1246.  
  1247.  
  1248.  
  1249.  
  1250.  
  1251.  
  1252.                                     -16-
  1253.  
  1254.  
  1255.  
  1256.  
  1257.  
  1258.  
  1259.         There are two commands for displaying a listing of the files accessible
  1260.      in a room.  The first command is
  1261.  
  1262.          .Read Directory <file-spec>
  1263.  
  1264.         If <file-spec> is empty, then all files are listed; otherwise, only 
  1265.      those files matching <file-spec> are listed.  For a full explanation of
  1266.      <file-spec>, see X.3.c.  Files are listed for the user as <name>
  1267.      <block size>, where block size is the size of the file in 128 byte blocks,
  1268.      which, not coincidentally, is the size of blocks used by XMODEM for file
  1269.      download.
  1270.  
  1271.         The second command is
  1272.  
  1273.          .Read Extended-directory <file-spec>
  1274.  
  1275.         which allows the user to see file descriptions "attached" to files.
  1276.         Files are listed in this format
  1277.  
  1278.      <name>  <size> | <description> <file date>
  1279.  
  1280.         which is formatted to the user's display.  Each file starts on a new
  1281.      line, thus providing a readable format.
  1282.  
  1283.         The descriptions for the files in a room are kept in a normal text file
  1284.      named FILEDIR.TXT, which must reside in that directory.  If the sysop
  1285.      wishes to create file descriptions for a set of files, the format of
  1286.      FILEDIR.TXT is simple, and it is
  1287.  
  1288.              <name><one or more spaces><description on one line>
  1289.              . . .
  1290.  
  1291.         FILEDIR.TXT must be in alphabetical order (case-insensitive) in order
  1292.      to function correctly.  The description may be no more than 7K long, and
  1293.      must reside on the same line as the name.
  1294.  
  1295.         The FILEDIR.TXT for any given directory room is updated by Citadel-86
  1296.      whenever a file is uploaded to that directory room, thus minimizing the
  1297.      maintenance chores of a Sysop with numerous directory rooms.
  1298.  
  1299.         Finally, if there is a file missing from FILEDIR.TXT (or if
  1300.      FILEDIR.TXT itself is missing), there is NOTHING to worry about.  There
  1301.      will simply be no file description displayed for the affected files.
  1302.      Further, excess entries in a FILEDIR.TXT does no harm to the listing
  1303.      (however, if you are fastidious you should research the Citadel-86 utility
  1304.      CULLDIR.EXE).
  1305.  
  1306.         The only weakpoint in FILEDIR.TXT is the fact that the entries must be
  1307.      in alphabetical order.  If they are not, file descriptions will not
  1308.      display at all.
  1309.  
  1310.      VI. 3. ii File transfers
  1311.         The second set of commands for accessing the directory of a room are
  1312.      those concerned with uploads and downloads.
  1313.  
  1314.  
  1315.  
  1316.  
  1317.  
  1318.                                     -17-
  1319.  
  1320.  
  1321.  
  1322.  
  1323.  
  1324.  
  1325.      VI. 3. ii. a Upload Protocols
  1326.         There are two protocols supported for the upload of files, XMODEM and
  1327.      YMODEM.  While this subject is covered in the FILES.HLP help file, we'll
  1328.      go over it here, too.
  1329.  
  1330.         The command format for uploading a file via XMODEM is
  1331.  
  1332.              .Enter File     or .Enter Xmodem File   or .Enter WC file
  1333.  
  1334.         The command format for uploading a file via YMODEM is
  1335.  
  1336.              .Enter Ymodem File
  1337.  
  1338.         After typing in any of these commands, Citadel-86 will prompt the user
  1339.      for the name of the new file.  If a file already exists by that name in
  1340.      the directory, the upload is aborted at this point; if the file name is
  1341.      not acceptable for any other reason (for instance, the name is special to
  1342.      DOS, such as CON:, or the user has attempted to specify a drive name),
  1343.      the upload is aborted.
  1344.  
  1345.         Once the filename is accepted, Citadel-86 will prompt for a description
  1346.      of the file.  If the subsequent upload is a success, the directory's
  1347.      FILEDIR.TXT is updated with the name and description of the new file.
  1348.      Citadel-86 will then ask if the user is ready to start the upload.  If the
  1349.      user responds negatively, the upload is aborted; otherwise, the chosen
  1350.      protocol starts in receive mode.
  1351.  
  1352.         YMODEM's BATCH mode is NOT supported for uploads by Citadel-86, for the
  1353.      reason that it would be very easy for a malicious user to abuse the system
  1354.      through the upload of numerous files.
  1355.  
  1356.      VI. 3. ii. b Download Protocols
  1357.         Three protocols are supported for downloads, XMODEM, YMODEM, and 
  1358.      straight text transfers, which is the default transfer protocol if neither
  1359.      XMODEM or YMODEM is specified (unlike the upload command, where XMODEM is
  1360.      the default).
  1361.  
  1362.         Command format is
  1363.  
  1364.              .Read [protocol] <Binaryfile|Textfile> [Formatted]
  1365.  
  1366.         XMODEM can be specified through both <X>modem and <W>C protocol (the
  1367.      latter may change, however, if WXMODEM is ever implemented).
  1368.  
  1369.         YMODEM is specified, of course, using <Y>modem.  When downloading
  1370.      files via YMODEM, only BATCH mode is available, even if only a single
  1371.      file is to be downloaded.
  1372.  
  1373.         The Binaryfile and Textfile specifications are synonyms, being a
  1374.      holdover from the CP/M days of Citadel.  However, the Formatted option
  1375.      can only be used with the Textfile option.  If a file is requested using
  1376.      the Formatted option, the file(s) requested (which Citadel-86 assumes to
  1377.      be normal MSDOS text files) will be formatted to the user's screen.
  1378.      Otherwise, the file is simply sent on a byte-by-byte basis to the user.
  1379.  
  1380.  
  1381.  
  1382.  
  1383.  
  1384.                                     -18-
  1385.  
  1386.  
  1387.  
  1388.  
  1389.  
  1390.  
  1391.         When an acceptable download command is entered, Citadel-86 will prompt
  1392.      for a filename from the user, which can be a <file-spec> (see X.3.iii).
  1393.      If more than one file matches <file-spec>, then all those files will be
  1394.      sent using the specified protocol.  In the case of XMODEM, this will
  1395.      probably be less than successful.
  1396.  
  1397.      VI. 3. iii <file-spec>
  1398.         A <file-spec> for Citadel-86 can range from being a single file (like
  1399.      "HELLO.TXT") to an ambiguous file specification in MSDOS format ("*.TXT"),
  1400.      to a list of files mixing both single file specifications and ambiguous
  1401.      file specifications.  For example,
  1402.  
  1403.              .Read Extended-directory *.DOC HELP.ME C*.HLP
  1404.  
  1405.      would display all the files that match any of those specifications.  Each
  1406.      part of the specification should be separated from the next by one or more
  1407.      spaces.
  1408.  
  1409.      VI. 4 Advanced Directory Options
  1410.         The listing of directory rooms and their associated MS-DOS
  1411.      specifications is kept in a normal MS-DOS text file named CTDLDIR.SYS,
  1412.      which resides in the #ROOMAREA directory.  While Citadel-86 automatically
  1413.      maintains this file at all times, not requiring any Sysop interference,
  1414.      the inquisitive Sysop can manipulate this file.
  1415.  
  1416.         The contents of this file is in this format
  1417.  
  1418.         <room #> <directory specification>
  1419.  
  1420.         The room # field should never be touched.  However, the second field
  1421.      can be changed when Citadel-86 is not up, thus changing the directory
  1422.      associated with the room specified by the room number.
  1423.  
  1424.         Really, though, there's not much reason to change this file manually.
  1425.  
  1426.      VII. OTHER COMMANDS MENU
  1427.  
  1428.      VII. 1 General Purpose
  1429.         The purpose of the Other Commands submenu of the Privileged Functions
  1430.      Sysop menu is to allow the Sysop access to commands that may be unique to
  1431.      the installation of Citadel in operation.
  1432.  
  1433.      VII. 2 Citadel-86 Other Commands
  1434.         Citadel-86 supports only two commands from this sub-menu -- a haphazard
  1435.      effort, indeed.
  1436.  
  1437.      VII. 2. a Deletion
  1438.         The <D>elete File option allows the sysop to delete any file in the
  1439.      MS-DOS file system.  Only a single file at a time may be deleted;
  1440.      ambiguous file names are not supported.
  1441.  
  1442.  
  1443.  
  1444.  
  1445.  
  1446.  
  1447.  
  1448.  
  1449.  
  1450.                                     -19-
  1451.  
  1452.  
  1453.  
  1454.  
  1455.  
  1456.  
  1457.      VII. 2. b Outside Commands
  1458.         The <O>utside Commands option allows the sysop to run programs from
  1459.      within Citadel-86 (but not concurrently).  Since it is sometimes
  1460.      inconvenient to take down Citadel-86 (e.g., from remote) in order to
  1461.      execute some utility or program, this option is, indeed, useful.
  1462.  
  1463.         When this option is selected, Citadel-86 will write a temporary
  1464.      CTDLTABL.SYS file (see INSTALL3.DOC, Section II.3.a) to disk, and then
  1465.      prompt you for a command line.  You may then attempt to run any program
  1466.      that you wish from the command line, simply as if you were running from
  1467.      the MS-DOS command level.
  1468.  
  1469.         The DOS shell is accessible at this point by simply typing a carriage
  1470.      return.  However, if you plan to use the DOS shell, you should observe
  1471.      two rules: always return to the current drive and directory (that is, the
  1472.      one that you find yourself in when you call the DOS shell) before typing
  1473.      the DOS EXIT command; and, second, avoid bringing up Citadel-86 again
  1474.      while you are in the shell.  While it's not fatal, and not necessarily
  1475.      damaging to do so, it can cause a lot of confusion if you do so.  (As if
  1476.      you weren't confused enough.)
  1477.  
  1478.      VII. 2. b. i Restrictions
  1479.         There are two actions that you should avoid taking while using the DOS
  1480.      shell from within Citadel-86.
  1481.  
  1482.         First, do not delete any of the Citadel-86 data files.  These are the
  1483.      *.SYS files, such as CTDLMSG.SYS, CTDLLOG.SYS, CTDLROOM.SYS, etc.
  1484.      However, you may delete or change the CALLLOG.SYS file (this was not true
  1485.      in earlier versions of Citadel-86).
  1486.  
  1487.         Second, do not run any of the Citadel-86 utilities which change the
  1488.      nature of the Citadel-86 data files.  These utilities include DATACHNG,
  1489.      RECOVER1, EXPAND, RECOVER2, etc.  You may run without fear those utilities
  1490.      which only show various things, like CLOG, CLRAY, etc.  In general, if you
  1491.      are not sure, either take your Citadel-86 down or experiment on a small
  1492.      test system.
  1493.  
  1494.      VIII. MISCELLANEOUS SUBJECTS
  1495.  
  1496.      VIII. 1 Wha....?
  1497.         Like anything that grows through accretion rather than planning,
  1498.      Citadel-86 has accumulated a clutch of features that don't really fit
  1499.      into any category.  So, rather than trying to create some categories
  1500.      that don't really fit into the great plan of Someone Out There, we
  1501.      decided to write a chapter with a central theme of mishmash that would
  1502.      contain all those features that don't really fit anywhere in particular.
  1503.      So, with no further shampoo ...
  1504.  
  1505.      VIII. 2 Chatty Questions
  1506.         When you drop into <C>hat mode to talk to a user, you will be faced
  1507.      with three questions before you're actually allowed to communicate with
  1508.      your victim.  These are the questions and the effects that your answers
  1509.      may cause:
  1510.  
  1511.  
  1512.  
  1513.  
  1514.  
  1515.  
  1516.                                     -20-
  1517.  
  1518.  
  1519.  
  1520.  
  1521.  
  1522.  
  1523.       Echo to Modem: This controls whether something received from the modem
  1524.      port should be echoed back to it.  You should usually answer Yes to this
  1525.      question when chatting with a user; if you use Chat Mode to call out
  1526.      manually, you should probably answer No, since otherwise you and the
  1527.      system that you call could get into a real nasty loop otherwise.
  1528.  
  1529.       Echo Keyboard: This controls whether what you type is echoed to the
  1530.      Console.  Answer Yes if you are chatting with a user; answer No if you
  1531.      are calling a system that will do echoing for you.
  1532.  
  1533.       Echo CR as CR/LF: This controls whether a CR should be translated into a
  1534.      CR/LF.  Yes is probably the correct answer when chatting with a user.
  1535.      When calling out using Chat, the answer may depend on the system that
  1536.      you are calling.
  1537.  
  1538.         Finally, you should know that when you call a system using the
  1539.      Network's <D>ialout command, the system drops you into Chat mode after
  1540.      dialing out.  You are not queried on the questions, however, in order to
  1541.      streamline operation; instead, all of the answers are No.
  1542.  
  1543.      VIII. 3 Chat Capture
  1544.         You, Chief High Sysop, have the ability to capture chats to disk if
  1545.      you choose to do so.  When you capture a chat, a warning will be printed
  1546.      to both you and the chattee saying that the chat is being captured; when
  1547.      you choose to stop capturing chat, another warning will be printed
  1548.      indicating that the session is no longer being captured.  In this way,
  1549.      you cannot successfully be accused of capturing chat sessions without
  1550.      warning.
  1551.  
  1552.         You turn on chat session during a chat by typing ^R (Control-R).  The
  1553.      system will then attempt to open a file named CHAT.TXT, and if it exists,
  1554.      the chat session should be appended to the end of that file.  If the file
  1555.      does not exist, it is created, and the resulting chat placed within.
  1556.  
  1557.         Typing a second ^R will result in the file being closed and the chat
  1558.      capture being turned off.  If you leave the chat session, the capture is
  1559.      automatically turned off at that point, and if you wish to continue
  1560.      capturing the chat (say, if you had to pop out for a moment and then
  1561.      returned), you must turn the capture back on again.
  1562.  
  1563.         By a chat session, we mean both a normal <C>hat, initiated by either
  1564.      you or a caller, and the chat sessions which are initiated by the <D>ial
  1565.      System command of the Network Menu, on which there should be more details
  1566.      in NETWORK3.DOC.
  1567.  
  1568.      VIII. 4 ESCaping Details of Chat Mode
  1569.         On rare, rare occasion it is necessary to send an ESC while in Chat
  1570.      mode.  Yet, Citadel-86 specifically tells you that an ESC let's you out
  1571.      of Chat!  How around this problem?
  1572.  
  1573.         By using the '\' key first.  When you do so, the system will pass the
  1574.      next key you press through without any interpretation, including the ESC
  1575.      key.  (If you need to send a '\', send two of them.)
  1576.  
  1577.  
  1578.  
  1579.  
  1580.  
  1581.  
  1582.                                     -21-
  1583.  
  1584.  
  1585.  
  1586.  
  1587.  
  1588.  
  1589.         And one more detail: when <C>hat is used, an ESC from either the
  1590.      caller or from the Sysop will cause the Chat session to end.  When
  1591.      <D>ialout is used, only the ESC from the system console will cause the
  1592.      system to end the Chat session.
  1593.  
  1594.      VIII. 5 Sysops Autodialing Themselves
  1595.         If your system becomes at all popular amongst the locals, you will
  1596.      rapidly find yourself in the position where you cannot get onto your
  1597.      machine whenever you like without committing foul and evil acts such as
  1598.      pulling the plugs out of modems and that sort of thing.  Since that tends
  1599.      to lead to bad reputations and negative karma, Citadel-86 gives the Sysop
  1600.      the ability to auto-dial him(or her)self; that is, you can tell the
  1601.      system, while someone else is on, that you are next in line to use the
  1602.      system. (aka "pulling rank".)
  1603.  
  1604.         To do so, simply type ^T (Control-T) while the person using the system
  1605.      is on.  The next time that the system looks at the keyboard (which is
  1606.      during <P>auses of output and other moments of the system waiting for
  1607.      input from the user) it will note that the ^T has been pressed and
  1608.      (usually) print out an acknowledgement to the system console only (the
  1609.      user will not be aware that you are anywhere near ground zero).  The
  1610.      status bar, which we'll discuss sometime along the way here, if you
  1611.      are using it, will also show that your ^T has been pushed.
  1612.  
  1613.         When the foul user logs out of the system, the system should
  1614.      immediately start beeping at you, once every ten seconds.  If you then
  1615.      hit anything on the keyboard, you get control of the system.  After
  1616.      2 minutes of beeping, the system will return its attention to the modem.
  1617.  
  1618.         If you type ^T twice while the user is on, this feature will be
  1619.      cancelled.
  1620.  
  1621.         If you type ^T when no one is on the system, the system will go into
  1622.      CONSOLE mode.
  1623.  
  1624.  
  1625.      VIII. 6 Denizens of the Status Bar
  1626.         Citadel-86 has a status bar.  This status bar gives you a vague idea
  1627.      of what's going on with the system, using various special messages during
  1628.      system initialization, and then a hint now and then about who's on.  The
  1629.      location of the status bar depends on the machine that Citadel-86 is
  1630.      running on.  If it is a PC Clone, it occupies the second line from the
  1631.      top of the screen.  If it is a Zenith Z-100, it occupies the 25th line of
  1632.      the screen.
  1633.  
  1634.  
  1635.  
  1636.  
  1637.  
  1638.  
  1639.  
  1640.  
  1641.  
  1642.  
  1643.  
  1644.  
  1645.  
  1646.  
  1647.  
  1648.                                     -22-
  1649.  
  1650.  
  1651.  
  1652.  
  1653.  
  1654.  
  1655.         The status bar should always have
  1656.  
  1657.         " Citadel-86 Vx.xx: "
  1658.  
  1659.      showing.  What shows up after that depends on the state of the system.
  1660.      Special messages appear right after it, but they only show up when the
  1661.      system is coming up.  Here's a generic representation of the status bar
  1662.      when the system is in normal mode:
  1663.  
  1664.      "Citadel-86 Vx.xx:<name of user><time of carrier>[<Chat sig>][<^T sig>]"
  1665.  
  1666.         "Chat sig" is a capital "C", and only shows up when you have Chat mode
  1667.      on.  ^T sig is a "^T", and only shows up when you are next in line to use
  1668.      the system.
  1669.  
  1670.      VIII. 7 Modem disabling
  1671.         You may have noticed that when you took control of the system by
  1672.      pressing ESC, the DTR light on your modem went out.  Or you may not have
  1673.      noticed.  But it did, or should have.  This leads to that age-old
  1674.      philosophical question, "When does this happen?"  Well, DTR comes down
  1675.      (or, more generally, the modem is disabled) when the Sysop takes control
  1676.      of the system and there is no carrier.  If there is carrier, then
  1677.      connection is maintained, even when coming out of the Chat mode initiated
  1678.      by the <D>ialout.
  1679.                                                               
  1680.           
  1681.      IX. QUESTIONS & ANSWERS
  1682.  
  1683.  
  1684.      ---
  1685.       Q. I'm completely lost, even after going through all of the below; what
  1686.      do I do next?
  1687.  
  1688.       A. Call your local (hopefully!) friendly C-86 Sysop.  For the most part,
  1689.      they're helpful, friendly people who are more than happy to help a new
  1690.      system get its feet under itself.
  1691.  
  1692.      ---
  1693.       Q. How do I create a "directory" room?
  1694.  
  1695.       A. Edit the room.
  1696.  
  1697.      ---
  1698.       Q. The system complains that it can't find CTDLBAD.SYS.
  1699.  
  1700.       A. There are two possibilities.  Either the file isn't there, or you
  1701.      currently do not have sufficient free RAM available.  Apparently, 192K
  1702.      RAM is no longer sufficient to run Citadel, so if you're running RAM
  1703.      disks or resident utilities that take up room, you may have to take one
  1704.      (or more) out to successfully bring Citadel up.
  1705.  
  1706.  
  1707.  
  1708.  
  1709.  
  1710.  
  1711.  
  1712.  
  1713.  
  1714.                                     -23-
  1715.  
  1716.  
  1717.  
  1718.  
  1719.  
  1720.  
  1721.      ---
  1722.       Q. When I try to bring the system up, it will come up momentarily but
  1723.      will then immediately give a crash message.  What happened?
  1724.  
  1725.       A. The first step is to look at the files on disk.  If there is a file
  1726.      called CRASH, it was created by, so look at it (this is a good General
  1727.      first step for most problems, too).  Within, there will be a fairly
  1728.      cryptic message which is more for debugging purposes, but can be useful
  1729.      to the new sysop, too.  If it indicates some sort of displeasure with the
  1730.      CALLLOG.SYS file, this is usually a good pointer to the possibility that
  1731.      you haven't configured MSDOS correctly in the FILES= area.  Check to make
  1732.      sure that your CONFIG.SYS file has the required FILES=20 line in it, and,
  1733.      if you had to put it in for Citadel, make sure that you have rebooted
  1734.      your system after adding it to the file.
  1735.  
  1736.       If there are still problems, then another observation is that an
  1737.      abnormally high BUFFERS= setting in CONFIG.SYS on systems that don't have
  1738.      a great deal of extra free RAM available will sometimes "steal" from the
  1739.      FILES= setting.  So, it's worth trying setting your BUFFERS= a little
  1740.      lower.
  1741.  
  1742.      ---
  1743.       Q. I try to use the <O>utside command in the <O>ther commands section of
  1744.      the Sysop Menu, but Citadel just says "Bad Return value".  What's wrong?
  1745.  
  1746.       A. In all probability, you don't have enough free RAM.  Use CHKDSK or
  1747.      some other utility to find out how much free RAM you have.
  1748.  
  1749.  
  1750.         Please submit other pertinent questions to Hue, Jr. at C-86 Test
  1751.      System for inclusion in this manual.
  1752.  
  1753.  
  1754.  
  1755.  
  1756.  
  1757.  
  1758.  
  1759.  
  1760.  
  1761.  
  1762.  
  1763.  
  1764.  
  1765.  
  1766.  
  1767.  
  1768.  
  1769.  
  1770.  
  1771.  
  1772.  
  1773.  
  1774.  
  1775.  
  1776.  
  1777.  
  1778.  
  1779.  
  1780.                                     -24-
  1781.  
  1782.  
  1783.  
  1784.