Fish 'n' More 2/fishmore-publicdomainlibraryvol.ii1991xetec.iso/dirs/cbbs_415.lzh/CBBS/CBBS.lzh/docs/readme

Text File | 1990-12-05 | 61KB | 1,514 lines

             CBBS V6.71b for the AMIGA (Kickstart V1.3)
                               VE5VA 7-Nov-90

      This program  is  basically  a CBBS 6.71 version of the W0RLI BBS.  It
 was  originally  put together for the IBM-XT by K3RLI, AG3F and others.  It
 is  written  in  the 'C' programming language which made it fairly easy for
 me  to  port to the AMIGA because I have been using C since 1974.  However,
 it  has had to be modified somewhat to make it work on the AMIGA.  Versions
 6.1e  and  later  have  also  had  modifications added to make CBBS talk to
 THEBOX  (a BBS very common in Germany).  It has been used extensively on an
 AMIGA  with  the  V1.3  Kickstart. It starts up and appears to work OK with
 Kickstart  V1.2  but  has  not been tested extensively.  It will work  on a
 system with 512K of memory.

      I have  run  it  on  a  single  floppy  drive,  although that required
 limiting  the  number of files on the BBS. With such limited disk space you
 will  only  be  able  to  handle  transfer of mail rather than running as a
 full-blown  BBS.  But  if you have a hard drive you can run a full-size BBS
 with  this program.  If you are already familiar with the CBBS or W0RLI (or
 even  MBL)  systems  you  should  have little trouble getting this thing to
 go.

      You MUST  be able to use the CLI and an editor in order to set the BBS
 up properly.

      I have  only  used  the  BBS  with a KAM and an old TAPR TNC1 with the
 upgrade  to  TNC2  V1.1.6,  but there should be no problem running this BBS
 with  others  such as GLB, PK232, PACCOMM etc. provided that they are TNC-2
 compatible  (if you are running one of these, read the info below about the
 problems  with  the  TAPR  V1.1.6  just  in  case  they apply to you).  The
 program  will permit KAM users to run one HF and one VHF port. It will only
 allow  connects from one side at a time but forwarding and logins to HF and
 VHF  can  be accomplished. For other TNCs you are stuck with running either
 VHF  or HF at any one time. I have not been able to modify the code so that
 it will handle multiple simultaneous connections.

      I have  done very little to customize the program for the amiga ... no
 menus  etc. There are two reasons for this. First, it's a lot of work and I
 don't  feel  like doing it. The source is here and compiles with MANX 5.0d,
 help  yourself! Second, there are other CBBS and W0RLI systems around which
 run  on  IBM  and  other disgusting machines. They all use the same command
 structure  so  if  you  can run the amiga BBS, you can run IBM etc.. But if
 the  commands  are all buried in menus you won't be able to switch to other
 machines.  Not  a  big  deal but another justification for me to leave well
 alone.

      The only  concession  to the amiga environment was to provide a window
 title  when  the BBS comes up. Clicking on the top-left 'close' gadget will
 make  the  BBS  shut  itself down in the same way as the 'Q' command except
 that  it  does  not  ask  you  if  you  are  sure you want to terminate the
 program.  The two numbers in the title separated by a slash are the highest
 message  number  and  the number of active messages. In earlier versions of
 CBBS  the  number  of  active  messages  was  exactly  that,  the number of
 messages  you  would see if you asked the BBS to list every mail message it
 had.  But  in  V6  this number also includes the number of messages created
 and  deleted  since  the  last  'GM'  command.   It also creates a new mail
 header  for  each  message  or  bulletin received even if it is rejected by
 CBBS  and  these  are  also counted even though they don't contain a useful
 message.   So  if the number of messages listed is way less than the number
 in the title bar, it's time to do a 'GM' command to clean up.




      I have  not  explicitly  modified  the  program  to  take advantage of
 available  ram:.  But  look  at the tnc.on file. When the program starts it
 dumps  the  tnc.on file into your TNC to initialize its parameters. It also
 allows  you to put CLI commands in that same file and you can, for example,
 set  up  your  config.mb  file so that help.mb, info.mb, user.dat, mail.dat
 and  other  files are specified as being in a ram: directory.  CLI commands
 must  then be put into 'tnc.on' to actually copy the files into ram: as the
 program  starts  up.  Thus, you don't need to load the files into ram: as a
 separate  operation  before  the  BBS starts up.  Your forwarding files can
 also  be modified so that after a regular forwarding operation or after the
 regular  console 'forward', the system copies mail.dat and user.dat back to
 disk.   (help.mb  and  info.mb are not modified by CBBS so they do not have
 to  be  saved  back to disk).  If you do this, you will also have to modify
 tnc.off  so  that  it  saves  the  files  when  the bbs is shutdown and you
 should  also  be  cautious that shutting the bbs down before the ram: files
 are  saved  could  leave  the bbs files in an indeterminate state.  Putting
 the  files  in ram: really speeds up the operation of the bbs especially if
 you  are  only  using floppy drives.  It also significantly speeds up other
 operations  such  as  untangling  the  mail  file and user files (GM and GU
 commands).  It  is  safest  to  specify  that the backup files mail.bak and
 user.bak are still on disk. Just in case.









































                 IF YOU ALREADY HAVE V6.6 or V6.5 INSTALLED

      If you  are  currently  using V6.6 then there are just two changes for
 you  to  make.  Copy  the  file  df1:cbbs/mb  off this disk to replace your
 existing mb program.

      Then copy   df1:cbbs/files/help.mb  off  this  disk  to  replace  your
 existing help.mb file.

      There are  no  major changes to the file structure and the system will
 run  as  it  did  with  V6.6  without any changes. However, there are a few
 features  added  in  V6.71 that are made available when you turn on options
 in  the config.mb file. Read the new manual.bbs Section 2.1 about automatic
 purging  of bulletins to see what these changes are. Read the file notes.67
 to see a summary of the changes from V6.6 to V6.71a.

      That should  be  all  that  is  required  to  upgrade  the  program to
 V6.71a.

      I have   fixed   a   bug  that  I  introduced  into  V6.  CBBS  should
 automatically  rename the log file at the end of each month and start a new
 one  for  you.   I forgot to copy this code into V6 and so it didn't do it.
 The  code  is  now present and your log file should now be renamed properly
 as stated in the manual.bbs file.







































         IF YOU ALREADY HAVE V6.1 INSTALLED (but not V6.6 or V6.5).

      If you  have  already been running a previous version of CBBS, such as
 V6.1f  then  the  installation  of  V6.71a will be easy for you.  There are
 three  changes  to  make.   First,  replace your current executable mailbox
 program  (mb)  with  the  one  on this disk, df1:cbbs/mb.  Second, you must
 make  one  change  to your config.mb file. The V6.5 (and earlier) config.mb
 file requires one extra line as shown here:

 ram:files/BID.MB
 ram:files/CALLS.MB
 files/states.mb            <<<---   ADD This line here
 20
 YES 14

      I have  shown  a  couple  of  extra  lines around the one that must be
 added  for  context  so  you  can find where it goes in the config.mb file.
 This  line  tells  CBBS  where  to  find  a  file  that  helps  it  resolve
 hierarchical addresses. If the file does not exist then CBBS ignores it.

      The states.mb  file  is included in the V6.6 (and later) distributions
 but I don't know much about it. You do not have to use it.

      The third  and  last  change  is  to  copy  the  new help.mb file from
 df1:cbbs/files/help.mb to replace your old version.

      Having done these three things, you are ready to start up V6.71a

      Read the  commands section of the MANUAL.BBS file on df1:. There are a
 few  changes  to  the  commands but none of them are major, and any changes
 that  I  made  to  CBBS  V6.1  have  been  put into V6.71a unless they were
 already incorporated into the V6.71a distribution itself.

      Also read  the  new section 2.1 in the manual.bbs file so that you can
 take advantage of the automatic purging of bulletins.



            FOR A NEW INSTALLATION OF CBBS - READ THIS PROCEDURE.

 ** Make a few backups of this disk!!!!!

 ** Print  out  this readme file, the manual.bbs file and the config.mb file
    which  is  in  the  'cbbs'  directory.  If  you aren't familiar with BBS
    systems  at  all  then read manual.bbs first very carefully. As you read
    through  it,  it  will  help to have the copy of the config.mb file with
    you.   But remember as you read it that it was intended for users of IBM
    machines  so  some references to things like DESQVIEW (ignore all of Ch.
    8!)and  windows  etc.  are irrelevant to you. (The IBM concept of window
    mentioned  in  the  manual is not the same as an AMIGA window and should
    be ignored).  You should then read through the rest of this file.

 ** If  you are going to use just this disk as the BBS then you will have to
    clean  up the space on it. Further, if you have only one disk drive then
    you  are  going  to have to change this disk so that it can be booted. I
    haven't  tried  that at all but it can be done.  Make a few backups, and
    then  you can delete vt100.doc, manual.bbs, the readme files, everything
    in  the  src  directory  if  you  don't want it online, and if there are
    commands in the c directory you won't use, then remove them too.




 ** The  TNC  MUST be wired up for HARDWARE HANDSHAKING.  If your TNC is not
    currently  wired  for  hardware  handshaking  then do it NOW.  My KAM is
    wired as follows:

    KAM Pin     AMIGA
       2          2
       3          3
       4          4
       5          5
       7          7
                6-8-20 (all jumpered together on AMIGA side only)


 ** Before  you  start  up  the  BBS  the TNC PARITY MUST be set to NONE (or
    SPACE).  On  my  KAM  no  parity  is "PAR 4" (and space is "PAR 3"). Any
    other  parity  setting  will  not work. You can use the vt100 program on
    this  disk  to talk to the TNC to set the parity before you start up the
    BBS.  When you use the Vt100 program make sure that it is using the same
    baudrate  as  your  TNC  or  you'll  just  get  garbage  on your screen.
    (Thanks  are  due to Frank, DF3UM, who suffered through this problem and
    brought it to light for me).

         There is  a  nasty  problem  with TNC1s that have the TAPR V1.1.5/6
    upgrade.   The  manual states that setting PAR to 0 or 2 means parity is
    set  to  none,  but  it  actually forces the parity bit to a one all the
    time  (i.e.  'mark'  parity).   The  BBS  expects parity to be forced to
    zero.  To  get  around this you can specify the '-t' flag when you start
    up  the BBS and the BBS software will strip the high order bit off every
    character  that  it  receives  from  the  TNC. This means you cannot use
    transparent mode even if I get it working in a future release.

 ** Your TNC  must have  the command already set:

    users 1  (on the KAM  'users 1/1')

    so  that  the  BBS will only permit one user at a time to connect to the
    BBS.   The  BBS  does  a 'conok off' whenever someone connects but it is
    safest  to  make  sure  that  nobody  else  can  get in with the 'users'
    command.  Your TNC should also have the command:

    autolf off

    This  command  is  not  essential  but  it  does  make the screen output
    clearer.  All of these commands can be put into the tnc.on file.

 ** It  is  safest  not  to use the 'runback' command when starting up CBBS.
    If  CBBS  is started up this way then it will definitely crash the AMIGA
    if  you  try  to  do  a  '!' command in CBBS. The best thing to do is to
    start  it  with  the  'run'  command  from  the  CLI or from within your
    df0:s/startup-sequence command file at reboot time.

         Here's part of my startup-sequence file:

    newcli  con:400/10/240/70/
    newcli  con:400/80/240/70/
    if exists df1:cbbs/mb
    cd df1:cbbs
    mb
    endif




         This creates  two  CLIs  for  me and then if I have my CBBS disk in
    drive  one  it  also  starts up CBBS for me.  The extra CLIs can then be
    used  to  edit  files or whatever else you want to do while CBBS runs in
    the  background. This start up procedure will leave the window for CLI 1
    open  until  you  terminate CBBS. The only problem this may cause you is
    that  the window takes up memory. You can always use the mouse to change
    the window to as small a size as possible.

 ** The  manual refers to use of transparent mode. I haven't implemented the
    necessary  stuff yet. DON'T USE IT. It definitely won't work if you have
    to turn off the 8th data bit with the '-t' flag.

 ** You  MUST edit the configuration file config.mb. There are two places in
    it  (obviously  marked)  where  you must put your callsign and one where
    you  must  put  your QTH. NOTE also that there is one place where a line
    generates  the current time in a message that is being forwarded. At the
    moment  the  timezone  printed  out  is CST. If you are not using CST on
    your  amiga you'll have to find the line and change CST to your timezone
    (or Z if you run your beast on UTC).  The line looks like this:

    R:$J/$KCST $M@$O [$Q]
           ^^^  Change this if necessary.

    The  structure  of  this  disk corresponds to the config.mb file but you
    can  change  it if you wish. If you have a hard drive you will certainly
    want  to have CBBS use that instead of a floppy. You can also set up the
    config.mb  file  so  that it will use two (or three) floppies instead of
    one  (i.e.  you can spread the BBS directories across two or more drives
    to   spread  out  the  load).   Unfortunately,  there  is  currently  no
    mechanism  for  spreading mail messages across two or more floppy drives
    - they must all be in the one directory.

         I have  changed  the  remote  sysop  password  scheme  in the amiga
    version.   It  is  described  later,  but you should change the existing
    example  password, which is at the end of the config.mb file, or replace
    it  with  one line containing a  single zero if you don't want to permit
    remote sysop.

 ** DON'T  change  the  port designators for the TNC and console terminal in
    the  config.mb  file.   They  MUST  be  'A'  (the TNC) and 'L' (console)
    respectively.   Any  other  port  designators  are  ignored and so are a
    waste of space.

 ** When  the  program starts up it looks for the file fwd.mb to define what
    it  does for forwarding files. This file will have to be edited.  I have
    left  parts  of my forwarding files here for you to look at as examples.
    As  distributed,  fwd.mb  contains just enough to forward to VE5OP which
    is  our  local  BBS  on  vhf.  NOTE  that  there  is a |a as part of the
    connection  string. This is only required if you have a KAM to force the
    forwarding  onto  VHF.  Similarly,  there are a few files (20m.fwd etc.)
    that  do  forwarding on HF and have a ~a in them.  If you aren't running
    a  KAM you must edit these out of the files as you'll only have one port
    to  use  anyway,  in  which  case  delete the two characters |a or ~a as
    appropriate.   Notice  also  that some of the TNC commands have a '/' in
    them.   These  are  specific to the KAM since many of its commands apply
    to  the  HF  and VHF ports. Such commands are specified as, for example,
    'retry  10/5',  which sets the retry parameter to 10 for HF and to 5 for
    VHF.  Similarly,  the  command  'retry  10/' sets the HF retry to 10 but
    leaves the VHF retry as it is.




         You can  make  CBBS  use  a forwarding file other than fwd.mb after
    the  BBS  comes  up  by using the 'YF filename' command. I often use 'YF
    20m.fwd'  to  change  from VHF-only forwarding to HF and VHF forwarding.
    The  HF forwarding is here as an example ONLY.  It won't work on the air
    for  you  unless  KC0TA has entered you in his user file as a BBS.  Note
    that  the  20m.fwd  file  refers  to  several  other  files,  and  these
    sometimes  refer  onwards to yet others.  The reason for this is to keep
    the  forwarding  info easy to manage (really!). Also, the file ve5op.via
    contains  an example of passing traffic by connecting to an intermediate
    KA-NODE.  Near the end of this file I have added a couple of examples of
    how to work out what should be in a forwarding file.

 ** When  the  program  starts  up it looks for the file 'tnc.on' which need
    not  exist  but  if  it  doesn't  your  TNC  had  better  be  configured
    properly.   If  you  are  going  to  use it, you MUST edit it to make it
    conform  to  your  configuration.  If you aren't going to use it, delete
    it.   The tnc.on file can contain comment lines (lines beginning with #)
    which  are ignored, and CLI commands (lines beginning with !). All other
    lines  are assumed to be commands to the TNC and are sent out the serial
    port.  The tnc.on file contained on this disk contains a lot of comments
    about  what it can do.  Some commands that could be in here are those to
    force  on  hardware  handshaking  and any other TNC parameters useful to
    the  BBS.  Even  if you only use the TNC with the BBS (and therefore you
    never  change  the parameters) it can help to have them 'softwired' into
    this  file  'just  in  case'.  You could, for example, put EVERY command
    your  TNC  understands  in  here so that if the TNC ever gets scrambled,
    just restarting the BBS will restore it's sanity.

         I have  commented  out  those  commands specific to the KAM. If you
    have  a  KAM,  edit  them  back in by removing the comment symbol at the
    beginning of each TNC command line.

         For TAPR upgraded TNC1s you MUST have the two commands:

    newmode off
    nomode  off

    in  the  tnc.on  file  because this is the ONLY combination of these two
    commands  that  will  work  properly.   This is not exactly what the BBS
    needs  but  is  as close as the TNC can get.  It works fine for the BBS.
    The  only  place  it  might  cause  you  problems is if you use the 'TA'
    command  and  connect  to  a station. On the disconnect the TNC stays in
    convers  mode  so  you  MUST remember to type '^C' (CTRL-C) to force the
    TNC  back  into  command  mode  before  you type '^E' to get back to the
    SYSOP prompt.

         In the KAM these commands are set to:

    newmode on
    nomode  off

    For  other  TNCs these commands should be set to whatever will cause the
    TNC  to return to command mode on a disconnect and to go to convers mode
    when  a  connection has been established. If your TNC won't do this then
    it is almost certain that the BBS won't work properly.

 ** For  TAPR  TNC1s  and  upgrades it is best to be sure of forcing the TNC
    into  hardware  handshake  mode  by  specifying  all  of  the  following
    commands in the tnc.on file:




    start 0
    stop 0
    trflow off
    txflow off

 ** When  you  terminate  CBBS, the last thing it does just before it closes
    the  serial  port  and  the  window  is  to send the content of the file
    'tnc.off'  to the TNC if the file exists.  The structure of this file is
    the  same  as  for  tnc.on  and  may also contain comments, CLI commands
    and/or  TNC  commands.   You  MUST  edit this file to make it conform to
    your  configuration  or  delete  it  if  you don't want anything done at
    shutdown.   If,  for  example,  you have set up the bbs to keep user.dat
    and  mail.dat  in  ram:,  then  this  file  should  contain the commands
    necessary  to write them back to disk before the program exits.  You can
    also  add  TNC  commands  such as the 'btext' command with a text saying
    that the BBS is off the air.

 ** The  AMIGA  has only one serial port (or at least my A-1000 does) and so
    the  gateway commands have been removed from the program.  They are only
    useful  if you have multiple serial ports, each with a TNC.  If you have
    a KAM, it'll gateway for you anyway!

 ** The  A,  AH, AI and user C commands have all been removed from the amiga
    version.

 ** The  'J'  commands  have  been  modified to print out the date that each
    call was seen as well as the time.

 ** A  'KL' command has been added for the sysop only. It kills a sequential
    list of messages but it will not kill traffic messages. For example:

    KL 103 117

         will kill  all  non-traffic messages between message number 103 and
    117  inclusive.  The BBS asks if you are sure before proceeding. In V6.5
    and  later,  the distributed IBM version added the ability to give up to
    four  separate  message  numbers to be killed to the 'K' command. So you
    could give the command:

    K 5 198 435 897

         and this  will  delete  only  message numbers 5, 198, 435, and 897.
    The  KL  command  was added at the request of Frank DF3UM who has a hard
    drive and sometimes must kill a large number of sequential messages.

 ** The   'L'   command   has   been  modified  to  allow the user to search
    for  titles   that   contain  a  specified substring. The user may add a
    quoted  string   to  any  'L'  command  and the command is then modified
    to  print  those  that  also  contain  the  string  in  their title. For
    example,

     LL 10
 prints the last 10 messages, but:

     LL 10 "amiga"

    prints   the   last   10   messages  that  have  the word "amiga" in the
    title.   The  quoted  string  may contain spaces if necessary. The sysop
    can also add the ';' modifier after a quoted string. For example,




     L@ amsat "microsat" ;
 will  print   any   amsat  bulletins that have the word "microsat" in their
    title and the BID and other information will also be printed.

 ** The  documentation  in  manual.bbs  does  not  explain  the  'M' command
    adequately.  The  'M'  works exactly like the 'S' command except that it
    requires  the  name of a text file as the SECOND argument on the command
    line.  This allows you to mail a single text file to a user or to create
    a bulletin from a text file. For example:

    mb all ram:text @ amsat #10

    will  create  a  bulletin in the same way as the command 'sb all @ amsat
    #10'  except that the text for the bulletin will be copied from the file
    'ram:text'.

 ** The  next  FIVE  changes,  described below, are optional. By default the
    system  has  these  four  options  turned  ON and will use them. But the
    sysop  can  turn any of them OFF by including a command in the config.mb
    file.  In  either of the port description lines (i.e. for port A or port
    L)  you  can  include  a descriptor of the form #a where 'a' is a letter
    corresponding  to  the  option  you  want  to  turn OFF. For example, my
    current port 'L' descriptor line is:

    LCE      300 10 600 100 10 0 27 8  0

         If I  wanted  to  turn option B off then I would include #B in this
    line:

    LCE#B    300 10 600 100 10 0 27 8  0

 ** OPTION  A.  I  have  made  a  change  to  the  way that this BBS handles
    bulletins  which  is  NOT in the standard CBBS. In order for this BBS to
    ACCEPT  a  bulletin from another system there MUST first exist a file in
    the  msgs  directory  (Note  that  the  name  'msgs' is specified in the
    config.mb  file  and  can  be  changed if you wish).  If for example you
    want  to receive ALLUS bulletins then there MUST be an ALLUS.dis file in
    the  msgs  directory.  If  no  such file exists then the program doesn't
    even  check  the  BID, it just says "NO - Don't want it".  This can save
    you  from  being  inundated  with  bulletins you don't want from another
    BBS.  This has happened to me, and with my limited disk space it doesn't
    take  too  many  ALLUS  bulletins before all my disk space is gone! Note
    that  in  order  to FORWARD a bulletin to another system you must have a
    corresponding  .dis file anyway, but my change requires the .dis file to
    ACCEPT a bulletin as well.

         The content  of  the  .dis file is a list of the callsigns (one per
    line)  of  those systems that you will forward that type of bulletin to.
    It  does  not  have  to  contain  the  name of the systems that you will
    accept  the  bulletin  from.   If  you  only receive bulletins and don't
    forward  them,  just  put  the name 'hold' in the .dis file, as is shown
    in the example .dis files on this disk.

         This option  can  be  turned  OFF  by  including  #A  in  the  port
    descriptor.   If  this  is  done  then  the BBS will accept any bulletin
    provided it doesn't already have it.

 ** OPTION  B.  There  is also a change to the way the BBS handles mail.  If
    the  BBS  receives mail addressed to someone who is in the USER.DAT file
    then  the  BBS  overrides  the  @BBS  field in the message with the @BBS



    field  from  the  user  file. This will occur whether the message is one
    you  typed  in  yourself  or  from  a  logged  in  user, or even in mail
    forwarded  from  another system. The assumption here is that if the user
    is  in  your  user list then the @BBS field is more likely to be correct
    than  any  mail  from outside. If the mail is addressed to a user who is
    not  in  the  user  file then the @BBS is not changed. I have found this
    option  quite  useful because users often type a send command such as 'S
    VE5DS'  and  they  don't specify a home BBS even though VE5DS's home BBS
    is  VE5OP  -  not  VE5VA.  With this option the BBS will put it in if it
    has one.

         This option  can  be  turned  OFF  by  including  #B  in  the  port
    descriptor.  In this case the @bbs field is not changed.

 ** OPTION  C.  There  is a modification to the pause() routine so that if a
    user  asks  for  information that could generate a long printout (EXCEPT
    for  a  Download),  then  after every 20 lines the BBS will print a line
    asking  if  the  user  wants  more. They can then either type a carriage
    return  to get the next 20 lines, or they can type Q which will stop the
    output.   As  an  example,  if  the  user types the command 'LL 100' the
    system will print this info out in blocks of 20 lines.

         To turn  this  feature  OFF put #C in the port descriptor.  In this
    case the BBS will send the output without a break.

         In V6.71a  I  have  added  option E which attempts to give the user
    the  ability  to  abort  the  output  from any 'L' or 'R' command.  Read
    option E and decide whether to use option C or option E.

 ** OPTION  D.  When  the BBS opens its window, by default it opens a window
    that  has  no  borders, cannot be resized,  and cannot be dragged around
    the  screen.  If  you  would  prefer a window with borders, resizing and
    dragging, then put #D in the port descriptor.

 ** OPTION  E. Due to the great demand, I have tried to implement a way that
    a  user  can  abort  the  output  from  CBBS  when  they do a 'L' or 'R'
    command.  If  they  type  'LL  100'  this  will produce a huge amount of
    output  and  the  user may change his mind and want to abort the output.
    Up  to now this couldn't be done other than by disconnecting. Now I have
    added  some code that will abort the output to the user if CBBS receives
    any  data  from  the  user.  Thus,  all  the user has to do to abort the
    output  is  type  a carriage return. There is not much point having both
    options  C  and  E on at the same time. Choose which you prefer and turn
    the other off.

         The reason  that  this is an option is that I cannot test it easily
    here  and  so  if  the  code  doesn't  work  properly  you have a way of
    shutting it off.

 ** Another  change  I  have  made  (but  not optional) is that if there are
    messages  to  ALL  on  your BBS and they are addressed TO your BBS (i.e.
    either  the  @BBS  field  is  empty  or it contains the callsign of your
    BBS),  the  beacon  does  not  just say ALL as most other systems do. It
    also  includes  the  highest  message  number  addressed  to  ALL,  e.g.
    ALL(489)  to  show that the highest message to ALL is numbered 489. This
    allows  users  to  see  when a new message to ALL has arrived at the BBS
    without them having to log in, they just monitor the beacon.

 ** There  are a few messages already in this BBS as distributed. They are a
    few  AMSAT  bulletins  which are really out of date now.  You can delete



    them  when  the  BBS first starts up.  Do a 'll 10' command to list them
    and  then use the 'K' command to kill them e.g.  K 1   will kill message
    number  1   and  so  on.  Then do a 'GM' command to clean out the files.
    You  must  periodically execute the 'GM' command anyway to clean out old
    files.  This  can  be done automatically or manually as described in the
    manual.   It  cleans up the space used by the mail files and deletes old
    ones.

         In CBBS  V6 a new feature was added such that deleted files can, if
    you  wish,  be  archived  instead of being deleted. If, for example, you
    want  to  archive  AMSAT  bulletins,  then  you  must create a directory
    called  AMSAT  immediately  under  the  CBBS  directory. Then instead of
    deleting  amsat bulletins when they get old, the program will store them
    in  the  amsat  directory.  NOTE,  I  think  it  is  dangerous to have a
    bulletin  board directory name the same as a bulletin name. For example,
    if  you  store  files about satellites in a directory called AMSAT, then
    the  'GM'  command  will  archive  AMSAT bulletins in there as well. The
    structure  of  archived  mail is not the same as a regular text file and
    you will not want your users trying to download these files.

 ** This  distributed  version  also  has a few BBS file areas.  You can add
    more  or  remove  some as you wish. But remember to create corresponding
    directories  for  the  new ones. The reason I have a specific write-only
    'upload'  directory  while all others are read-only is that a user might
    upload  a  file containing arbitrary binary characters and then download
    this  same file to themselves. It is possible that the bad characters in
    the  file  will  mangle  your TNC.  Alternatively, a user might upload a
    file  that  contains  obscenity or is commercial in nature and you would
    not  want to be held responsible for distributing it any further.  So to
    avoid  this,  users  can  upload  a file into the specific area and then
    send  you mail telling you that it is there.  You can then move the file
    to  its  intended  area  after  you  are sure it is safe to do so. Thus,
    users  can't  write  into  the normal file areas and can't read from the
    upload area.

 ** The  content  of the file 'files/info.mb' is sent to any user who issues
    the  'I'  command.  It  currently has two lines in it briefly describing
    that  this  is  the  CBBS program. If you want to, you can edit the file
    and  add  to  it  your name, qth and the type of TNC, Rig etc.  that you
    are using.

 ** The  !  SYSOP  command  that  allows  you  to execute CLI commands works
    except  that  the  output  of  a CLI command goes to the window in which
    CBBS  was started, NOT to the CBBS window itself. This is annoying but I
    can't  find  a  way  around  it  yet.  On  the  other  hand,  this  is a
    multitasking  machine and you can always have a separate CLI window open
    to  execute  CLI commands anyway. So I'm not gonna bust a gut to sort it
    out.

 ** In  my  version  of  CBBS  the  remote  sysop  password does NOT work as
    described  in manual.bbs.  I felt that the password mechanism used there
    is  very  weak and it wouldn't take a determined snooper very long to be
    able  to  break  into  your system remotely if remote sysops use it very
    often  (NOTE  that  in  order  for  someone  to successfully be a remote
    sysop,  you  must first set that privilege for them in the user file AND
    set  the  'R'  privilege for port 'A' in the config.mb file AND set up a
    proper password as described below).

         Instead of  using a line containing 64 characters, the new password
    scheme  uses  a  line  (or  lines) containing up to 64 positive non-zero



    integers.   If  a  remote  user  tries to get in, the system still sends
    them   four   numbers   as  a  challenge  but  instead  of  sending  the
    corresponding  letters  of  the password, the remote sysop must send the
    SUM of the corresponding numbers.

         Since you  can't  easily  fit 64 numbers on a line, you can put the
    numbers  on  several  lines with all but the last line terminated with a
    backslash character. For example:

    17 42 93 81 90 3 27 82 103 35 72 64 13\
    76 7 25\
    23 47 56 62 18 11 95 79 126

    Using  this  example  password, if a user tries to be a remote sysop and
    receives the challenge

    10 21 7 16

    then  they  must  answer  with  105 (the sum of the 10th, 21st, 7th, and
    16th  numbers  in  the  list).  There MUST be at least 20 numbers and no
    more  than  64 in the list AND they must all be positive and non-zero or
    the  remote  sysop function will be disabled. Thus, if you don't want to
    permit  the  remote sysop function at all just put a single zero on this
    line.   The  numbers  should  all  be  different  and in random order to
    strengthen the password scheme.

 ** In  V6.1e  and  later  versions,  I added two things to the window title
    bar.  If  the  sysop  has  mail  (i.e. the sysop callsign appears in the
    Btext  "Mail  for:")  then  the  text "You have mail" will appear in the
    title  bar.  Also,  the  name of the current forwarding file is shown on
    the  right  hand  side of the window title bar. There is still a bug (as
    of  V6.6)  in  this code that it does not always put the "You have mail"
    in  the  title bar even if you do have mail. I have not quite sorted out
    what's happening here.

 ** In  V6.1e  (and  all  later versions) I have also added modifications to
    make  CBBS  talk  to THEBOX which is a bbs system that is very common in
    Germany.  THEBOX only accepts an 'S' command from users or other BBS but
    it  then  internally  classifies  each  message into Personal, Bulletin,
    Control  or  $  (another  kind  of  bulletin). When it forwards, it then
    generates  the  appropriate  SP,  SB,  SC or S$ command. I have modified
    CBBS  so  that  when  it  receives 'S' commands from users or any BBS it
    processes  them slightly differently. The changes are insignificant when
    talking  to other CBBS systems or to users. But when talking to a THEBOX
    system CBBS will reject the 'SC' command and change 'S$' into 'SB'.

         THEBOX also  generates  a  'lifetime'  field  on bulletins which is
    indicated  by '#nnn' as the LAST item on the 'S' command line. The 'nnn'
    indicates  how  many  days  the  bulletin is to be kept before it can be
    deleted.  I have modified the structure of the mail header to include an
    unsigned  character  which  contains  the lifetime of the bulletin.  The
    'S'  command has  been modified so that it will accept the #nnn lifetime
    field  from  anyone.   The  lifetime  is  now  also used when the system
    determines  whether  a  bulletin is stale. Any bulletin which is created
    from  any  source  without a lifetime field will have the lifetime field
    set  to  the default bulletin lifetime field that is already in the CBBS
    config.mb  file.  The  description  of  this  line  in manual.bbs begins
    "Number of days old a bulletin is ....".

         CBBS now  checks  for   THEBOX  when it receives either the [DL5UY-



    ....  -] or [THEBOX- ... ].  So, every bulletin no matter where it comes
    from  has  a lifetime field and if CBBS detects that it is forwarding to
    THEBOX,  then it will add the lifetime field on a bulletin. The lifetime
    field  is now shown to the sysop if he edits a bulletin and the lifetime
    field can be modified if he wishes.

         One slight  change  has  been  made  to the way CBBS handles an 'S'
    command  to  make  it  conform to THEBOX.  If the command itself is just
    'S'  (not  'SP',  'SB'  etc.)  and  the message is being sent to a valid
    callsign  then  the  message  will be made a Personal one, otherwise the
    message  will  become  a  Bulletin.  CBBS used to leave the message type
    blank.

 ** The  distributed  version  of CBBS V6.71 has modifications that allow it
    to  pick  up  mail  from  a user's KAM if the KAM is V3.0. KAM V3.0 will
    accept  a  reverse  forward request and will send any outgoing mail from
    its  user to any BBS that logs in and asks for a reverse forward. I have
    made  one  extra  change  when  handling  a KAM V3.0. The KAM only sends
    personal  messages  but  the user could put, for example, a command such
    as:

    S all @ allus

         The distributed  version  of  CBBS  for  the  IBM  will make this a
    personal  message  and  also  will Hold it for the SYSOP to check out. I
    have  modified  CBBS so that it automatically changes this to a bulletin
    and creates a BID for it.




































                   ***###***  OK .. Let's try it ***###***


      You MUST  first  be  connected  to  the directory that contains the mb
 program  and  the  config.mb  file,  which  on  this  disk  is  the  'cbbs'
 directory.   This is because the config.mb file in this distributed version
 has  all  the  directories  specified  as  being  relative  to  the  'cbbs'
 directory.  You  can change this as you see fit.  Then execute a command of
 the form:

    mb [-bN] [-t] [-d] [config-file]

 The  default  baudrate  between  the TNC and AMIGA is 9600 baud. If you use
 any  other  speed  then you MUST specify the -bN switch to tell the program
 what  baudrate  to  use .. e.g.  -b1200 (NOTE that there's no space between
 the b and the number!)

      The '-t'  option  (which can be specified before or after the '-bN' if
 it  is  also  present)  specifies  that the BBS software must strip off the
 high  order  bit  of every character received from the TNC. This allows the
 BBS  to  be  used  with  TNCs  that set the parity bit to a one when in 'no
 parity' mode, such as the TNC1 with the TAPR upgrade to TNC2 V1.1.5.

      The '-d'  option is only used to set a debugging flag and is of no use
 to you unless you modify the source code.

      The program  can  be  told  to  use  a  different config file than the
 default  name  of  config.mb  by  specifying  the  name  as the config-file
 argument.

      It takes  a  few seconds of disk churning to load the program but then
 the  first  thing  that should happen is that it opens a new window for the
 BBS  and  the  title  should  appear.  It then prints a line containing the
 words  Window  and Port .. ignore this.  It first sends an XON, followed by
 a  Control-C  followed by a carriage return. These will wake up a TNC if it
 has  been  XOFF'd and the Control-C will force a KAM into packet mode if it
 was  being  used for RTYY, AMTOR etc.  Then it tries to send three commands
 to  the  TNC: 'm off', 'cono off' and 'echo off'.  If you have forgotten to
 connect  the  TNC to the amiga serial port or have set it to the wrong baud
 rate  or wrong parity, then after about 30 seconds the program will timeout
 and  exit  because it can't get a reasonable response from the TNC. Connect
 it  up properly and start again.  It then sends out 'TXD' and looks for the
 'TXD'  reply  from  the TNC. This gets the program and TNC synchronized and
 allows  the  program  to  ignore  any stuff in the TNC memory that it might
 have monitored while the BBS was off.

      The program  then sends a PASS command to the TNC to find out what the
 pass  character is. If it finds one it also sends a STREAMSW command to the
 TNC  to  find  out  what the stream switch character(s) is(are). On the KAM
 there  are  two,  one  for  VHF and one for HF. The program then prints the
 results of what it found.

      If you  have  included  CLI  commands  at the front of the tnc.on file
 then  the  process may pause a bit here, especially if you include commands
 in  tnc.on  that  load  some  of the bbs files into ram:.  Then the program
 should  show  some  data  from the TNC as it dumps the tnc.on file into the
 TNC.   It  then  prints  out  how  many  calls  are  in  the  calls.mb file
 (initially  zero)  and  you  can ignore it when it reports that the file is
 full.   It  then  should  print  a  line  saying  how many users are in the
 USERS.MB  file. First time through it should say zero. (You had better have



 set  your  call in config.mb already because the program automatically adds
 you  to  the  user file as a sysop, of course). It then prints out how much
 free  chip  and fast memory it can find and it will report that it is going
 to use 16K or 14K, ignore it.  It then prints:

    BT mail for:

 and after a couple more lines it should just go quiet.

      It is  now  waiting  for someone to call into it on the TNC or for you
 to  wake  it  up as SYSOP from the keyboard.  As SYSOP you type a Control-E
 character  (default  in  config.mb  and  can  be changed) at which point it
 should  send  the  commands  'm  off'  and  'conok off' to the TNC. It then
 grinds  the  disk  a second or so and then it should print the sysop prompt
 which  the  distributed  config.mb file has set to 'SYSOP>' (you can change
 it).   From  there  on  you can issue the commands described in manual.bbs.
 As  an  example,  just type the command DU at the prompt. It should display
 just  your callsign first time through because you are the only user it has
 seen  so  far.   A useful exercise at this point is to use the 'EU' command
 to  edit  your  entry  to  add your name.  As users log in and give the BBS
 their  name and zipcode, the file will begin to grow. You can add new users
 yourself  if  you wish by using the EU command with their callsign. E.g. to
 add me:

    eu ve5va

 and  then set the other parameters (such as name, zipcode etc.) as shown in
 the manual.  Another command to try is:

    LL 10

 which asks the BBS to list the 10 most recent messages in the mail file.

      One thing  you  must  keep an eye on, especially if you are only using
 floppy  disks, is that if you have allowed logging of events (in config.mb)
 the  log file, files/log.mb, will grow without bound as the BBS is used. So
 you  must  occasionally  delete  this  file.  If you are required by law to
 keep  a  record,  print the file out or archive it on another disk and then
 delete  it  from the bbs disk.  Try out the 'PRTLOG' program which prints a
 summary of the file.

      To exit  from  sysop mode just type the 'B' command. It will then wait
 for a user to call in.

      The safest  way  to  terminate  the  program  is by clicking the close
 program  gadget  in  the  window  title  bar  or  use  the Q command on the
 keyboard.  This  is  so  that the program will update the user and possibly
 the  mail  files  properly.  Just removing the disks might leave them in an
 indeterminate  state  whether or not you have stored them in ram:. Also, if
 you  have  CLI commands in the tnc.off file to do some tidying up, the only
 way they can be executed is to quit properly.

      If disaster  strikes  and  you  lose  the  mail.mb file then it can be
 recovered  as  long as you still have the individual mail files in the msgs
 directory.   Running  the  'cbbs/msgs/mbrestm'  program  will  recover  the
 mail.mb file for you.








      Here are a few pointers, based on experience.

 ** If  the  BBS  opens  the  window  but  then  closes it and generates the
    "Timeout  - .." message it can be for one of the three reasons listed or
    others  I  haven't thought of or run into yet. Make sure that the TNC is
    plugged  into the serial port. Also make sure that the cable is wired up
    properly.   If  neither of those help then try running the BBS with "run
    mb -t" to tell it to ignore parity.

 ** If  you  call another BBS but it won't accept mail from you, or it won't
    send  you the [BBS-TYPE-CODES$] message, then you must log into that BBS
    as  a  normal  user and send mail to the SYSOP asking him/her to set you
    up  as  a  BBS in his/her user file. It also helps to have them also set
    you  up  as  an  expert user (although you can do that yourself) because
    this usually reduces the size of the login message.

 ** If  your  BBS  won't  forward bulletins make sure that you have a proper
    .dis  file for the bulletin in the msgs directory and that the .dis file
    contains a proper list of callsigns.

 ** If  your BBS won't accept bulletins from another BBS (i.e. your BBS says
    'No  -  Don't  want  it')  then  you  do  not  have a .dis file for that
    bulletin  type.   There  must be a .dis file for that bulletin type even
    if  you  don't  forward  the  bulletins  to  anyone  else. NOTE that the
    bulletin type is the @ field of the bulletin.

 ** If  your  BBS won't forward mail for a user then either that user is not
    listed  in  your forwarding file for their BBS or their user record does
    not specify the correct Home bbs.

































                          Some Forwarding Examples

      The best  way  to  work out a forwarding file is to log in manually to
 the  system  that  you  are trying to forward to and record everything that
 occurs.  Then work out the forward file from that.

      First, a  simple  example.  I  wish to forward to VE5OP who is here in
 Saskatoon.  If  I  connect  to  VE5OP manually I see this (with my comments
 added on the right):

 c ve5op                              [ I type this command
 cmd:*** CONNECTED to VE5OP           [ and the TNC says I'm connected
 [CBBS-6.0-H$]                        [ Here's the BBS login message
 EU>                                  [ from VE5OP and its prompt.

 Now  let's  add  the  corresponding  forwarding  commands on the right hand
 side.

 c ve5op                              [  CC VE5OP
 cmd:*** CONNECTED to VE5OP           [                   <NOTHING HERE
 [CBBS-6.0-H$]                        [  HA0023C VE5OP
 EU>                                  [


      The 'CC'  command  not  only  sends  the first connect message, but it
 also  looks  for  the '*** CONNECTED' message from the TNC. So you must NOT
 use  the  'R'  command  to read the '*** CONN' message.  Remember that once
 you  get to the [BBS-TYPE-CODES$] message you are in to the BBS and now you
 just  use  an  'F',  'H' or whatever list and you simply add in the list of
 calls  whose mail is forwarded to VE5OP.  So the complete script could look
 like this:

 CC VE5OP
 HA0023C VE5OP
 ve5op                                 [ you can put lots more calls
 ve5pf                                 [ in here as well as
 ntssk                                 [ nts codes
 97*                                   [ or wildcards
 *** EOF

 KAM  users  should  remember  to  add  the streamswitch characters into the
 initial connect command (e.g. 'C|aC ve5op' for VHF).

      If I  had  to  go  through  the VE5USR digipeater to get to VE5OP, the
 only change in the script would be:

 CC ve5op via ve5usr

 because  the  digipeater  would  not  generate  any  more  text  during the
 connection.

      A more  complex  example  is if I want to connect to the VE5AGA BBS in
 Regina,  which  is  165  miles  from  Saskatoon.  I  have to go through two
 KA-NODES  (VE5BAR  and VE5ABO) and one digipeater (VE5GF) to get to VE5AGA.
 The path is in this order:









  VE5VA <-> VE5BAR-3 <-> VE5ABO-3 <-> VE5GF <-> VE5AGA
   bbs       ka-node      ka-node     digi        bbs

 Here's  what  I  would  see if I logged in manually with my comments on the
 right hand side:

 cmd:c ve5bar-3                                   [ I send the connect
 cmd:*** CONNECTED to VE5BAR-3                    [ and my TNC responds.
 ###CONNECTED TO NODE VE5BAR-3(VE5BAR) CHANNEL A  [ Now KA-NODE responds
 WELCOME TO SASKATOON...VE5OP LOCAL BBS...        [ with its own messages
 ENTER COMMAND: B,C,J,N,X, or Help                [ until it prints the
 ?c ve5abo-3                                      [ prompt without a CR.
 ###LINK MADE                                     [ Connected to ABO
 ###CONNECTED TO NODE VE5ABO-3(VE5ABO) CHANNEL A  [ and ABO now prints
 Welcome to the Ituna Node                        [ its own messages
 ENTER COMMAND: B,C,J,N, or Help                  [ up to the prompt
 ?c ve5aga v ve5gf                                [ now connect via digi
 ###LINK MADE                                     [ The KA-NODE says OK
 [MBL-5.12-C$]                                    [ Now the BBS responds
 Welcome to the Regina BBS                        [ with all its own
 de Perry VE5AGA                                  [ login messages
                                                  [ which can be anything
 for latest information 'D INFO.TXT'              [ up to the prompt
 VE5AGA>                                          [ with '>' at the end.

 And here's the script with the corresponding forwarding commands.

 cmd:c ve5bar-3                                   [ CC VE5BAR-3
 cmd:*** CONNECTED to VE5BAR-3
 ###CONNECTED TO NODE VE5BAR-3(VE5BAR) CHANNEL A  [ R###CONN
 WELCOME TO SASKATOON...VE5OP LOCAL BBS...        [ R!
 ENTER COMMAND: B,C,J,N,X, or Help                [ R!
 ?c ve5abo-3                                      [ SC VE5ABO-3
 ###LINK MADE                                     [ R###LINK
 ###CONNECTED TO NODE VE5ABO-3(VE5ABO) CHANNEL A  [ R###CONN
 Welcome to the Ituna Node                        [ R!
 ENTER COMMAND: B,C,J,N, or Help                  [ R!
 ?c ve5aga v ve5gf                                [ SC VE5AGA VIA VE5GF
 ###LINK MADE                                     [ R###LINK
 [MBL-5.12-C$]                                    [ HA0023C VE5AGA
 Welcome to the Regina BBS
 de Perry VE5AGA

 for latest information 'D INFO.TXT'
 VE5AGA>

 Note  that the '?' prompt from the KA-NODEs does not have a carriage return
 after  it  and  so there is just a corresponding 'S' command here.  The 'R'
 command  must not be used here because it is looking for a line ending with
 a  carriage  return  and the BBS will just hang and eventually timeout here
 if  you  use  'R'.   IF  the  KA-NODE sent  a prompt with a carriage return
 after  it  (i.e.  '?<CR>'  instead  of  just '?') then you would need a 'R'
 command  to  read  the  '?<CR>'  and  then  an 'S' command to send the next
 command  to  the  KA-NODE.   You  can easily tell the difference because if
 there's no <CR> then you will see:

 ?c ve5abo-3                        [ only requires SC ve5abo-3

 such  that  both  the  prompt  and  your next command are on the same line,



 whereas if there were also a CR there you would see:

 ?                                  [ would require R!  (or R?)
 c ve5abo-3                         [               SC ve5abo-3

      When you  use the 'R' command you can specify some context expected on
 the  line  such as the 'R###LINK' I have used here. It is useful to do this
 rather  than  'R!'  for  the  'LINK' or 'CONNECTED' messages because if the
 link  fails then the ka-node will send a message such as '###RETRIED OUT AT
 NODE  VE5ABO-3'. This does not match the specified '###LINK' and so the 'R'
 command  will  fail  and  your BBS will disconnect the forward attempt.  If
 you  had  specified  'R!'  instead of 'R###LINK' then 'R!' will also accept
 '###RETRIED  OUT'  and  then  your script will hang until the process times
 out.   However,  you  don't  need to specify a context for all the lines so
 that  some of them are just read with 'R!'. The 'R' command will search for
 its  given string anywhere on the line so that you could check for '###LINK
 MADE'  by  specifying  'RMADE'  as  well as 'R###LINK' or  'R###LINK MADE'.
 Just  how much context you give is up to you as long as it is sufficient to
 correctly distinguish the line from any other expected response.

      Note also  that  VE5AGA  has  a  much  longer  login message than does
 VE5OP,  but  that  doesn't  matter. Once your BBS sees [BBS-TYPE-CODES$] it
 will  look  for  the  prompt  with  the  '>'  symbol  in  it and then start
 forwarding.

      If the  VE5GF  digipeater were between the ka-nodes rather than at the
 end,  then  the script would not be any more difficult. For example, if the
 order of the connections were:


  VE5VA <-> VE5BAR-3 <-> VE5GF <-> VE5ABO-3 <-> VE5AGA
   bbs       ka-node      digi      ka-node      bbs


 The connection process would then be:

 c ve5bar-3
 c ve5abo-3 via ve5gf
 c ve5aga

 so  the  basic  script  would  look  like this (with some of the extraneous
 stuff removed):

 CC ve5bar-3
 R###LINK
 etc.
 SC ve5abo-3 via ve5gf
 R###LINK
 etc
 SC ve5aga
 R###LINK
 HA0023.....
 etc.


      This procedure  for  working out a script can also be used for working
 through NET/ROM nodes and other types of networking or gatewaying nodes.






                              The BBS commands


      The BBS  commands  (as  opposed  to  commands  used  for  storing  and
 forwarding  mail) are fairly easy to use. The primary use of these commands
 is  to  store information of local interest that you would not want to mail
 to  everyone.  Rather, you can store the information in a file area and let
 users  read  the  information  if they are interested. For example, on this
 BBS  I  have  put a file area for QRP related information. Other file areas
 could  be  for  AMSAT  information,  and another for a swap'n shop file. If
 someone  is  interested  in  QRP stuff but not in AMSAT info  they can look
 through  the  QRP area and not have to read a lot of mail or bulletins that
 don't interest them.

      I'm going  to  use  my  local BBS VE5OP as an example here to show how
 the commands work.

      The first  command  to  give  to the BBS is the 'w' command which asks
 what  are  the  major  areas  in  the BBS. If I type 'w' on the VE5OP BBS I
 receive this info:

 Use W and directory ID:
 WA --> Amsat / Oscar                 WB --> General information
 WC ---> ARRL/ Newsletters            WD --> Hamfests and Related EVENTS
 WE --> Packet Meetings-Minutes,ect.  WF --> Packet LISTS
 WG --> Swap 'n Shop                  WH --> Local Users - Equipment
 WI --> NEW Uploads To Here Please
 If  I want to see what is in the 'General information' area then I type the
 'WB'  command  as  shown beside the name of the area. The 'WB' command will
 print out:

 AA4RE           4k | Q.BAS           3k | README.R95     16k
 CONFIG.MB       4k | README.DOC     12k | WOOD1.INF       2k

 41k of 31834k used, 27348k free.

      Now let's look at the AMSAT area by typing the 'WA' command:

 AO-13.SKD       2k | MIR.QSL         1k | O13.OCT         3k
 MIR.BCN         1k | MIR89.FEB       4k | O13.SEP         5k
 MIR.MAR         8k | MISC.021        2k | WEATHER.021     5k
 MIR.OPR         4k | O13-1.OCT       4k | WOOD1.INF       2k

 41k of 31834k used, 27348k free.

      And also  let's  see  what's  in  the  swap'n  shop area with the 'WG'
 command:

 890416.SWP      7k | SWAP04.DEC      7k | SWAP20.FEB      7k
 890523.SWP      7k | SWAP12.MAR      8k | SWAP29.JAN      6k
 SWAP0122.89     6k | SWAP2.NOV       8k | VE5BBL.SEL      1k

 57k of 31834k used, 27348k free.

      Now, I  decide  that  I want to look at what is in the file mir.qsl in
 the  amsat area. To do this I must Download the file and tell the BBS which
 area it is in ('a') and it's name. So I type the command:

 da mir.qsl




 and receive the following info:

 ARRL BULLETIN 140  ARLB140

 MIR SPACE STATION COSMONAUTS U1MIR AND U2MIR ARE NOW REPORTED TO BE
 OPERATING ON 145.400 MHZ.  QSL CARDS SHOULD BE SENT VIA USSR, MOSCOW,
 107207, P.O. BOX 679, B. STEPANOV.

 WA2ILB @ NN2Z>

      In this  case  the  file  contains  an  ARRL  bulletin but it could be
 anything.

      If a  user  wants  to  send  a  file  to the BBS then the file must be
 Uploaded  into  the  'I'  area and a filename must be specified for it. For
 example:

 ui qrp.info

      The BBS  will  respond by telling the user to upload the file and then
 terminate  it  either  with  '^Z' or with '/ex'.  The user should also send
 mail  to the SYSOP to tell them that the file has been uploaded and what is
 in it.

      The 'W'  commands can also by used by the sysop so you can try them on
 the  distribution  disk.  But  the SYSOP cannot use the upload and download
 commands. They mean something different when the SYSOP uses them.






































                         Summary of Changed Commands



      This section  briefly  summarizes  the  changes  I  have  made  to the
 standard CBBS commands.

 - The A, AH, AI commands have been removed.

 - The  user  C commands have been removed. And the SYSOP 'C' command to set
    the  clock  has  also  been  removed.   This  leaves only the sysop 'CM'
    command.

 - The J command also prints the date along with the time.

 - The  L<,  L>  and  L@  commands will now allow a wildcard in the callsign
    argument.

 - Any  L  command  can  have  a  quoted string appended to it to list those
    messages that contain the string in their title.

 - A KL command has been added for the sysop only. A command such as:

    KL 107 115

         will Kill  all  messages  numbered  from 107 TO 115 inclusive.  The
    command  will  NOT  kill  traffic  messages.  In the standard IBM V5 and
    later  releases  the  'K'  command  has also been modified from previous
    releases  so  that  it  will  allow  you  to  specify up to four message
    numbers to be killed by the one 'K' command.


 - Several  minor  changes  have been made to the 'S' command (and therefore
    to   the   'M'  command  also).  First,  CBBS  will  accept  a  lifetime
    specification  as  the  very last item on the command line. Second, if a
    message  type  is  not  specified  then if the message is addressed to a
    valid  callsign  then  the  message  will  be  stored as a Personal one,
    otherwise it will be stored as a Bulletin.
























      Good Luck.

      If you   have   problems  getting  CBBS  to  work  either  because  my
 instructions  aren't clear or I've left out something important, please let
 me  know.  If you want help or have questions I'll be glad to help IF I can
 but you must take note of two things.

    - I  will  not  answer  mailed  queries unless you also send me a proper
      SASE.  U.S.  hams  PLEASE  note  that  putting  a  U.S.  stamp on your
      envelope  won't do me any good. Canada Post expects me to use Canadian
      stamps.   However,  I  will  take  a  LOOSE  U.S.  stamp (30 cents) in
      exchange  (NO  IRCs please - I have plenty right now).  If you send me
      a  disk  and  expect  it  back, that will require correspondingly more
      stamps (about one dollar).

    - I  have  been  ill  since  Sept  1984  with  Chronic  Fatigue Syndrome
      (Myalgic  Encephalomyelitis  to  you  Brits ... I'm one myself) and am
      always  tired.  I  put  this BBS together over many months (it took me
      six  months to find a simple bug in my amiga code!) . So if I'm having
      a  bad  spell  I  may  not  get  around  to answering for a while.  Be
      patient.

    (This is my new mailing address as of October 1990)
    Pete Hardie VE5VA
    567 Delaronde Road,
    SASKATOON
    SASK   S7J 4A7
    CANADA

 or HF packet
    VE5VA@VE5DA (14.107) or VE5VA@VE5RF (7.103)

 or BITNET
    [e-mail]

 or USENET
    alberta!herald!hardie

























 There  are  a  few  hams who also can supply you with the latest version of
 C-BBS. If they are closer to you than I am then try them first.


 Frank Schmitt  DF3UM@DB0IE
 Barlachstr 4,
 WD-6908 Wieslach
 GERMANY

 Grisandi Giampaolo  IW4CEA@IW4CEA
 Via Lago Di Garda 39
 48100 Ravenna
 ITALY

 Crauwels Walter   ON1AOT@ON6AR
 Heirbaan 31
 2510 Mortsel
 BELGIUM

 Rene van Stipriaan  PE1KBJ
 Dovenetelweg 94
 NL-1508 CJ  Zaandam
 HOLLAND