



























                   __________________________________________
                  <                                          >
                  < Mutant BBS -- Version 1.1                >
                  < Copyright 1994 by Tom Johnson            >
                  < Multinode Documentation - Feb 12, 1994   >
                  <__________________________________________>
                   




                                Table of Contents


     Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . .    1

     Multi-Node Setup  . . . . . . . . . . . . . . . . . . . . . . . .    1

     Command Line  . . . . . . . . . . . . . . . . . . . . . . . . . .    2

     Waiting for Caller Data . . . . . . . . . . . . . . . . . . . . .    2

     MODEM.LOG . . . . . . . . . . . . . . . . . . . . . . . . . . . .    2

     Events  . . . . . . . . . . . . . . . . . . . . . . . . . . . . .    2

     Command Control Codes (CCC) . . . . . . . . . . . . . . . . . . .    3

     Output Control Codes (OCC)  . . . . . . . . . . . . . . . . . . .    3

     Security Access Code Strings (SACS) . . . . . . . . . . . . . . .    3

     Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . .    3

     Door Formats  . . . . . . . . . . . . . . . . . . . . . . . . . .    4

     MAILER.CTL  . . . . . . . . . . . . . . . . . . . . . . . . . . .    4

     Menu Command Codes  . . . . . . . . . . . . . . . . . . . . . . .    4

     Chat Groups . . . . . . . . . . . . . . . . . . . . . . . . . . .    6

     User Editor . . . . . . . . . . . . . . . . . . . . . . . . . . .    6

     Technical Notes . . . . . . . . . . . . . . . . . . . . . . . . .    6

     Final Notes . . . . . . . . . . . . . . . . . . . . . . . . . . .    7




     --- Mutant BBS v1.1 Multinode Documentation --- Page 1

     Introduction
     ------------
          Mutant includes some multinode support.  However, at this time, I
     do not have adequate equipment to test this support extensively nor
     information on file sharing, etc. (I just putted around until
     something seemed to work).  For these reasons, I am putting the
     multinode extensions in a separate document and do NOT guarantee that
     they work.  Therefore, I recommend backing up your files up daily.  I
     have tested Mutant with two nodes running under Desqview and tried the
     multinode extensions and things which I thought may cause problems. 
     However, Mutant handled them fine.

     Multi-Node Setup
     ----------------
          Not much is required to run Mutant as a multi-node system.  Of
     course, you need some sort of multinode capability such as running
     under Desqview or running multiple copies on different computers
     connected to a LAN.  Also, SHARE (or equivalent) must be installed. 
     Once you've met these requirements, you are ready to set-up Mutant.  I
     am presuming you've set it up in single-node usage based on the info
     in MUTANT.TXT.

     1.   run "mtnt config" to access the configuration editor.
     2.   Make sure your temporary directory does not contain an extension. 
          Then create "tempdir.xxx" for node numbers greater than one,
          where "xxx" is the node number.  For example, if you have in
          system config, "c:\mtntemp" and you have two nodes, you would
          create "c:\mtntemp", "c:\mtntemp.2".  Mutant needs these separate
          directories for the temporary files it creates/stores in the
          directory.
     3.   Enter and create a node directory (i.e. "c:\nodedir"). Mutant
          stores node information, messages to other nodes, and multinode
          chat information in this directory.  I would allow 5k*# nodes
          free space in this directory.  I doubt the files will ever exceed
          1k a piece, but just in case.
     4.   Create separate configuration files in case your modem
          information is different.  You will need to use the "/Cname"
          parameter to load/edit these configurations.
     5.   If you are not using the sample files,  set-up a multinode menu
          (see below for the commands) so users can list nodes, chat, etc.
     6.   Well, that's about it.  One final step is running Mutant and
          telling it that it's multinode (you might like a batch file to
          save keystrokes).
     7.   To run multinode, run "mtnt -N [params]" where "xxx" is the node
          number (1-255) and "params" are any optional parameters you may
          need.  If the "-N" parameter is not given or "xxx" is zero,
          Mutant will not run Multinode.
     8.   That should do it, now for some notes and multinode info.




     --- Mutant BBS v1.1 Multinode Documentation --- Page 2

     Command Line
     ------------
     "-Nxxx"   - where "xxx" is the node number (see above).
     "CLEANUP" - When Mutant runs and finds the "node.xxx" file in the node
                 directory, it will assume the node is already up.  Next,
                 it will ask you if you wish to continue.  If you say yes
                 or wait a minute, Mutant will just assume it had crashed
                 and run.  Using the "CLEANUP" option will cause an
                 automatic "Yes" response.
     "-D"      - Normally when Mutant exits, it will mark itself as down in
                 order that you can run a frontend without locking up
                 another node trying to run an event.  As most frontend
                 mailers let you ignore all calls during events, this isn't
                 a problem.  However, if you do get a frontend that does
                 not allow such a setup, please specify this flag such that
                 the "down for event" event types can take place.

     Waiting for Caller Data
     -----------------------
          The file SYSSTAT.DAT is called SYSSTAT.x for node numbers two and
     above where 'x' is each nodes number. The WFC screen will display
     information about the node not the entire BBS.  Having separate files
     allows you to see which nodes get more active callers.

     MODEM.LOG
     ---------
          This is the file Mutant creates when using modem "diagnostics". 
     For node numbers two and above, this is called MODEM.x where 'x' is
     the node number.

     Events
     ------
          Set Node if you only want the event to run on a specific node. 
     Otherwise, set it to zero and the first free node will run the event. 
     Normal events (Echo/Net posted, at logoff, logon events are not
     normal) will only be run by one node if you set node to 0.  If you
     want a normal event to run on all nodes (such as a menu event), you
     should use the duplicate event command for each node and set the node
     for each node.

     Down -   By setting this, the following will happen:
               1.   The node running the event will send a message to the
                    other nodes telling them to go "down" for the event.
               2.   The node will wait until all nodes state that they are
                    "down for event" (including those waiting for caller in
                    a front door!).
               3.   Other nodes will go "down for event" after the caller
                    logs off or while waiting for a caller.
               4.   The node will run the event.




     --- Mutant BBS v1.1 Multinode Documentation --- Page 3

               5.   Other nodes will ignore attempts to logon.
               6.   When done running, the node will send a "go up" message
                    which releases logon constraints.
               7.   If Mutant is run, it checks for any events which are
                    "running" and have "down" and are on this node.  If it
                    finds one, it will send a "go up" message to the other
                    nodes.
          Events have been the biggest problem in writing multinode.  I've
     looked at other BBS programs for how they do events and most don't
     accomplish what I want.

     Command Control Codes (CCC)
     ---------------------------
          The "m" parameter can be one of the following:

              # -   Door can be run on only ONE node.
              $ -   Door can be run on only ONE node.  Also, do not keep
                    statistics information for the door.
              % -   Door can be run on multiple nodes.  However, do not
                    keep statistic information for the door.  This would be
                    the same as not specifying "name", but this allows you
                    to define a name for the door that shows up when other
                    nodes list nodes.

     You can use "%N" in the parameters to specify the node number (1-x). 
     For example: 

          "#The Pit"c:\pit\pit.exe %N

     will allow "c:\pit\pit.exe" to be run on one node.

     Output Control Codes (OCC)
     --------------------------
     ^\N - Displays the node number

     Security Access Code Strings (SACS)
     -----------------------------------
     Nx - BBS node must be at least 'x'.  For example, N1 means multinode
          only. N1' means single line only since Mutant treats single node
          usage internally as node 0.

     Protocols
     ---------
          If a protocol uses a logfile, make sure it is unique for each
     node since shared logfiles would confuse Mutant.  If you have a '?' in
     the logfile name, Mutant will put in the node number and try to open
     that file (i.e. DSZ.? would be DSZ.1 for node 1).  Make sure you've
     informed the protocol of this option by setting it's environment
     variable on each node.  If you are running a multitasking system,




     --- Mutant BBS v1.1 Multinode Documentation --- Page 4

     create a batch file to run the BBS which sets the environment variable
     per window.

     Door Formats
     ------------
          When using the "OPENFILE:" command, the filename can include a
     '?' in which case, Mutant substitutes the node number.  Supposedly,
     RBBS' "DORINFOx.def" is supposed to contain the node number, but that
     only allows 1-9.  So, if you use "OPENFILE:DORINFO?.DEF" make sure you
     only have at most 9 nodes.
          Also, the "NODE" command is a numeric variable and represents the
     node number(See Mutant.doc for info on door formats).

     NOTE: if you can not distinguish the filenames for different nodes,
     try placing the door format in the temporary directory.  For example:

     d:\tflip\tflip.com tfl%N.CFG %S"5:\PC Board v14"

     MAILER.CTL
     ----------
          For node numbers two and above, this file is called "MAILER.x"
     where 'x' is the node number.

     File Areas/CD-ROM support
     -------------------------
     If you set the CD-ROM flag in a file area, before Mutant will copy the
     file from the drive to the hard drive, Mutant will make sure another
     node is not performing a CD-ROM to hard drive copy.  Mutant will wait
     up to five minutes before it will assume something is wrong and then
     continue with the copy.  This is designed to prevent two users from
     downloading from CD-ROM(s) at the same time and forcing the drive to
     seek back and forth or from a CD-ROM changer from changing disks back
     and forth.

     WARNING: When you setup your file areas, be sure they are on aliased
     drives.  Your 'C' drive is not the same for all nodes (unless you're
     just multitasking).  I ran into this problem on my board and it caused
     interesting things to happen.

     Menu Command Codes
     ------------------

     Code:700
     Desc:List Nodes
          Lists all nodes, their status and who is on them.




     --- Mutant BBS v1.1 Multinode Documentation --- Page 5

     Code:701
     Desc:Send Message to a node
          Allows the user to send a one-line message to a user on another
          node.  

     Code:702
     Desc:Create Chat Group
          Allows the user to create a chat group.  They are then the
          sponsor of the group.

     Code:703
     Desc:List Chat Groups
          Lists all public chat groups and those private chat groups which
          the user has been invited to join.

     Code:704
     Desc:Join Chat Group
          The user is prompted for the number to join.

     Code:705
     Desc:Toggle Do Not Disturb Flag
          If the user does not wish to receive messages from other nodes,
          they can set the Do Not Disturb Flag which will prevent messages
          from other nodes being displayed.

     Code:706
     Desc:Lock Node
          This sets up a temporary log on event for a node or all nodes. 
          You will be prompted for a node number.  Enter a number 1-? to
          lock a specific node, -1 to lock all nodes, but this node, or -2
          to lock all nodes.  Then, enter the SACS for the logon event.  If
          you enter nothing, the temporary logon event is removed from the
          specified node(s).

     Code:707
     Desc:Interrupt Node
          This will force a user (or users) off when they return to a menu
          prompt.  You specify the node the same as lock node.  You will
          then be prompted for a hang-up string, if just hit ENTER, Mutant
          will use the hangup string defined in the system configuration
          for this node.  If you desire this to function the same as the F5
          key, I will do so.

     Code:708
     Desc:Take down node
          You enter the node the same way as lock node.  You will then be
          prompted if you wish to take down the node(s).  All this does is
          affect the Quit Next (Ctrl-F8) flag.  If a user is online, the
          node will go down when they logoff.




     --- Mutant BBS v1.1 Multinode Documentation --- Page 6

     Chat Groups
     -----------
          Chat groups are ways a user can chat with each other.  Chat
     groups have a name and a sponsor.  The person who creates it is the
     sponsor of the group and names the group.  Chat groups can be private
     or public.  If they are private, the sponsor must "invite" users to
     join the group.  The concept of groups seems like a waste since you
     will probably have no more than 10 nodes, but it was the only way two
     users could chat privately among themselves.

     There are special commands that users can access while chatting:

     "/O"     - Logoff immediately
     "/LEAVE" - Leave the chat group
     "/WHO"   - Display who is in the chat group
     "/NODES" - List nodes
     "/HELP"  - Display this list of commands

     Sponsors also have the following commands:
     "/KICK:name" - Kick a user out of the group.  If the conference is not
                    private, they can rejoin.
     "/INV:node"  - Invite the person on "node" to join.  They are sent an
                    invitation message and marked as invited so that they
                    can join a private group. If the "node" has their DND
                    flag set, they will not get the inivite message.  Also,
                    once a user leaves a group, they must be reinvited if
                    the group is private.
     "/PUBPV"     - Toggle the public/private status of the group.

     While a user is chatting, the "F10" terminal window key has a special
     function.  You do not chat privately with the user.  Instead, a window
     pops up at the top of the screen in which you can type a message that
     is sent to the group.  Use F10 again to close the window.  While in
     this window, you can not switch windows nor resize the window.

     There is a possible bug which I think I have successfully removed, but
     I'll describe it anyway.  If more than one user leaves the group at
     the same time, the group data file may be incorrectly updated and the
     group may not be deleted if all the users leave the group at the same
     time.  If this happens, let me know and I'll look into it.

     User Editor
     -----------
          Modifying a user via the User Editor or menu codes 3xx will cause
     "messages" to be sent to all nodes.  If you edit a user which is on
     another node, the user's information may be reloaded into memory and
     any changes (such as msgs posted, uploads/downloads) to be lost.

     Technical Notes




     --- Mutant BBS v1.1 Multinode Documentation --- Page 7

     ---------------
          That's all there is to Mutant's multinode capabilities.  Since I
     had no clue on how to handle file conflicts, I will describe how they
     are handled (skip this if you could care less). If you have some
     knowledge of a better way, I'd appreciate the input.

     1.   Files are left open as long as they are accessed.  You may notice
          this when you use "F2" to shell out while reading messages,
          listing files, use menu codes 300, etc.
     2.   Files open for read only are opened with DOS' DENYNONE file mode. 
          This allows other nodes to read the file and write to the file as
          long as DENYALL/DENYREAD is not used.
     3.   Files open for write, but only plan to write to the end of the
          file or modify a record are opened with DENYWRITE which permits
          read access.
     4.   Files open for write, but may make major changes to the file, are
          opened as DENYALL which denies subsequent read or write access to
          the file.  This is mainly used to prevent pack events, delete a
          file from the file listings, etc. from corrupting other nodes.
     5.   If a node tries to open a file, and fails, the board checks to
          see if the file exists(via a directory search) and if so, it
          waits.  If a user is on during this waiting, they will be
          informed of the file trying to be accessed.  The user can opt to
          press 'A' (yes, a capital A) in which case the open fails and the
          specified action should be aborted.  This is where the major bugs
          may be since I might not have handled an open failure properly in
          some places.
     6.   That's about it.  No File Locking is performed since DOS allowed
          opens to take place on a locked file, but then generated a
          critical error when a read or write is attempted on the file and
          I didn't wish to inform the nodes each time a file was opened
          that they could not have access to the file.
     7.   This worked well under my Desqview test. I did things such as run
          a Mutant event while reading messages to see how it handled it. 
          Just for you info, the pack attempt will be put on hold until the
          user is done reading the messages.

     Final Notes
     -----------
     1.   Because of the overlays, multitaskers such as Windows and some
          version of Desqview are unable to run MTNT with SHARE installed
          (which is required).  I have solved this problem by placing the
          overlays in a separate file (rather than in the .EXE).  So, if
          you have this problem, please ask for a version of Mutant that
          comes with MTNT.OVR along with MTNT.EXE.
     2.   Any and all input as to the multinode operation of Mutant would
          be appreciated.  Also, success reports would be nice.  Finally,
          since you are setting up multinode operation at your own risk, no
          additional charge will be required for registration (unless you




     --- Mutant BBS v1.1 Multinode Documentation --- Page 8

          feel like it).  Besides, it costs enough already to run multinode
          with the phone bills, equipment costs, etc.
