Media Share 9/MEDIASHARE_09.ISO/hamradio/mb1501a.zip/MB1501A.EXE/README.DOC

Text File | 1992-11-25 | 16KB | 407 lines

     Created for packet community by:

      Hank Oredson, W0RLI
      21390 Shannon Lane
      West Linn, OR 97068

  Several people have kindly volunteered to act as regional coordinators
  for questions, bug reports, etc.  Those I know about are:

  G4WPT  @ G4WPT  -  For the U.K.
  JA1KSO @ JA1KSO -  For Japan and the Far East.
  LU3AGJ @ LU3AGJ -  For Latin America.
  VE3GYQ @ VE3GYQ -  For North America.

  N6IYA  @ N6IYA  -  John can provide the MailBox on floppy disk.
             Any flavor of 5 or 3 inch diskette.
             The MailBox files are more than 360k, so if you
             require 360k disks, send two ...
             Self-addressed mailer and formatted diskette required.
             John Smith, 1060 Pine Drive, Felton, CA 95018
             New releases go first to John for test, then to:

  WA6RDH @ WA6RDH -  New versions are placed on the WA6RDH dialup system:
             [phone]



     The code will run under DoubleDOS, DESQView, Windows, or OS/2.


       Running multiple copies of the MailBox.

     To run multiple copies, simply execute MB again in another window
     or partition. All files and ports may be shared by up to 16 copies
     of MB. Each copy will create it's own log file.




  If you are upgrading from a version 11, 12, or 13 release, MB will
  automatically update your existing MAIL.MB amd WP.MB to a new file version.
  This may take some time, and will cause a lot of disk activity.
  No extra disk space is required.  Just be patient, it will finish.

  *** Notice: if you are upgrading from a version prior to V11.0, there
  is something you must do before you continue. There was a change to
  the structure of the WP database in V11. If you now run a version
  prior to 11.0, before you even think of reading this any further,
  save your current WP database using the IA command: IA WP.TXT

  Ok, that worked, right?

  Now delete or rename your old WP.MB

  When you bring up the new version for the first time,
  reload your WP database:
  IR WP.TXT
  That is all there is to it.


  Each of the major functions of the MailBox runs in it's own window.
  For the MailBox itself, there can be several windows running at the
  same time, each serving a different user.

  MB.EXE - the MailBox.

  MBSTAT.EXE is separate function that can be run in it's own small window.
  It provides a running display of current MailBox activity.

  NW.EXE, The Net Walker, is a tool for tracing the connectivity of a
  NET/ROM or TheNet network.

  LM.COM, the MailBox "Lock Manager", becomes resident at
  system startup and provides various services to the MailBox.
  LM must be run prior to starting DESQview.

  MBINIT.EXE, the MailBox initialization, is also called at system startup.
  It loads global data into LM, checks that the TNC's are alive,
  and provides other startup functions.

  I recommend that you use the G8BPQ switch as interface to your COM
  ports.  For those that do not wish to use the switch, or cannot,
  a simple COM port driver is provided:

  FBIOS.COM, the Serial Port Handler, is loaded at system startup to
  provide replacement for the DOS provided COM ports.
  Note that FBIOS does not handle the MS-400 type 4 port cards.
  For those cards, I suggest you use MBBIOS, provided by AA4RE.

  FBIOS, MBBIOS, or the G8BPQ switch must be run prior to starting DESQview.

  MBSTAT.EXE   -  MailBox status display.

  RECOVER.EXE  -  Message and User database recovery program.

  SERVER.EXE, the Server function, is a general server interface.
  It can be used to call user written modules that extend the functionality
  of the MailBox. A very simple server called ECHO (source and executable)
  is provided as an example of how to create a server. Many servers are
  now available for use with the MailBox. Some examples are:

  ECHO     - Created by W0RLI, returns a message.
  FILEX  - Created by W0RLI, provides REQFIL, REQDIR, and upload functions.
  REQDIR - Created by WB3AFL.
  REQFIL - Created by WB3AFL.
  REQCB  - Created by W0RLI for the J-Comm and RT Systems Callbook databases.
  SMTP     - Created by K3MC, provides MailBox/smtp message interchange.

  See SERVER.DOC for more information about servers.


  PRTLOG.EXE is a MailBox log file analyzer. It can be used to produce
  summary reports of MailBox activity.



  The MailBox Directory path (\BBS) is hardwired.
  All MailBox data files (*.MB) and all message files go into this
  directory.  The executables may, of course, go anywhere you like.

  Thank you all for testing the previous versions, and thank you
  in advance for testing this version as well. The changes in commands,
  and any bug fixes, are noted in CHANGES.MB. As usual, there are
  probably changes in INIT.MB, CONFIG.MB, and PORTS.MB.

  Run MBINIT to reset the MailBox system if a task crashes.
  DO NOT run LM or MBINIT if any tasks are running,
  exit from all tasks first.

  Minimum system requirements: IBM AT, or XT with V20 processor.
  It is possible to run the code without a hard disk, but NOT recommended.

  The number of ports, port speed, and number of tasks that
  can be run depend on the speed of the system. Assuming 1200
  baud radio data rate and 9600 baud tnc to computer data rate
  the following guidlines apply. With a "standard" 6 Mhz. AT,
  four or five ports with four to six tasks can be run.
  With a "standard" 4.77 Mhz XT (with V20), two ports and two
  or three tasks will work. With a fast 386, at least six ports
  with eight tasks are ok. I have tested a 6 Mhz AT with two 1200
  baud radios, one 19,200 baud computer/computer link and
  one 300 baud radio. It worked ok. See DV.DOC for more details.
  I presently run a 25 Mhz 386DX with 6 radio ports (1 - 300, 1 - 9600,
  4 - 1200 baud) and one wire link at 19,200 baud, with 8 tasks.

  Kantronics KPC-4 and KAM require firmware revision 2.85 or later.
  TNC2 should have firmware V 1.1.5 or later.
  TNC1 should be run no faster than 4800 baud.


  1) Backup all files in the MailBox directory (\BBS).
     In case something goes wrong, you will be able to restore
     everything to where it was without loss of messages.

  2) Customize Edit INIT.MB, MOTD.MB, INFO.MB, CONFIG.MB, NEWUSER.MB,
     FWD.MB, DIST.MB for your site and configuration.

     Put in your call, name, qth, and zip (or postal) code in the appropriate
     places. Set up various subdirectories for user files and for MailBox working
     files. Setup the port definitions to correspond to the hardware on your
     computer.

     Verify that all files required by the MailBox are
     in the MailBox directory (\BBS).

  3) Make certain CONFIG.SYS and AUTOEXEC.BAT have parameters
     set to handle the MailBox. Here is a typical example:

     In CONFIG.SYS (example) :

     files   = 60      <- Roughly 8-10 per MB task
     buffers = 60      <- With DoubleDOS, make this 20
     stacks  = 0,0     <- You may need 16,64, or 0,0 depends on DOS version

     In AUTOEXEC.BAT (example) :

     share     <-  Load the DOS SHARE command.
     lm      <-  Load the MailBox lock manager.
     bpqcode     <-  Load the g8bqp switch.
     ytnc 20 2 1 <-  Required for version 4.05 or later of bpq switch.
     mbinit     <-  Initialize the MailBox.


  4) In case of crash:
     It is most important, if the system crashes for any reason,
     to do the following, in this order:

     CHKDSK /F
     RECOVER
     MBINIT

     This will gaurantee that there is no loss of data.
     It is smart to put the CHKDSK /F and RECOVER into your AUTOEXEC.BAT
     so they are always run at system startup.

  It is a good idea to run some sort of disk cache.  The MailBox can
  be quite disk intensive.  HYPERDisk, NORTON Cache, and other popular
  disk caches all appear to work well.    If you enable "delayed write"
  this will speed things considerably.


  Approximate window sizes required:


     FT     - 40k
     MB     - 74k
     MBSTAT - 25k
     MON    - 50k
     NW     - 40k
     SERVER - 125k  (minumum, this will support the ECHO server)
          300k  (this will support most any server)

  If things do not work right, increase the window size until they do.


         Known restrictions.

There can be at most 110 pending different message destinations. These
are the calls that show in the beacon text plus any calls in AT fields
of messages that have not been forwarded. The only time this might cause
a problem is if you keep many bulletins on the system, and they are
not marked as read ("Y") or forwarded ("F").


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

         Message manipulation.

One problem that confronts the sysop from time to time is the message
that has the wrong type, wrong distribution list, etc. There are two ways
to correct this problem.

1) Use the "E" command and edit the message header. Because of the many
   possibilities, this command is limited in scope. For simple changes,
   such as "unkilling" a message, it will work. It will not create a
   distribution list.

2) Copy the message to a file and then make a new message.
   This is simpler than it sounds. It requires two commands.
   Here is an example. Assume someone sent a message to KB6BHN, and
   instead of using SP KB6BHN @ W0RLI used instead SB KB6BHN @ ALLUSA.
   Assume it was message number 325.

   First put the message into a file using the F command:
   F 325 J
   This puts the message into file J.

   Then make the new message:
   MP J KB6BHN @ W0RLI
   You can either enter the orignal title, or, since you had to do
   all this work to correct a users error, just give the new message
   a blank title!

   Now kill the orignal message.
   K 325

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

     PRTLOG.EXE - The log file analyzer.

    PRTLOG OUT.PRT -opt

The output is placed in file OUT.PRT.

Options: -L lists the entire log.
     With no options you get the usual monthly summary.

PRTLOG prompts for the names of log files to process.


       Log file format

   Each line in the log file contains an event code, the date and time,
   followed by further information about the event.

   'C' - User connected to system.

      'A' -> 'K' - A user connected on that port.
    Next char shows type of connect: "U" - User, "S" - bbs.

      'L' - User was linked via the station that just connected.
      'S' - "connect" from local console (sysop).

   'X' - Exit.

      'A' - Owner put MailBox on line.
      'B' - User said good bye.
      'D' - User disconnected.
      'E' - Excluded user attempted connect.
      'F' - User forced off by sysop.
      'I' - Pogram startup. Note: connect on port I will have IS or IU.
      'Q' - Exit from program.
      'T' - Timeout, forced disconnect.

   'F' - File event. Command line shown as user entered it.

      'D'  - File downloaded.
      'K'  - File deleted.
      'U'  - File uploaded.

   'M' - Message event. Message number always shown.

      'D'  - Message copied to file.
      'E'  - Message exported.
      'F'  - Message forwarded.
      'FE' - End of forwarding session.
      'FR' - Start of reverse forwarding within forwarding session.
      'FS' - Start of forwarding session.
      'FZ' - Message forwarded. Message size shown.
      'K'  - Message killed. Note KS is auto-kill of old bulletin.
      'P'  - Message printed.
      'R'  - Message read.
      'SE' - End of server session.
      'SS' - Start of server session.
      'Z'  - Message entered. Message size shown.

      'C'  - Message entered. Obsolete log entry format.
      'M'  - Message entered. Obsolete log entry format.
      'S'  - Message entered. Obsolete log entry format.

   'H' - Houskeeping event.

      'S'  - Start of Housekeeping event (obsolete).
      'B'  - Clean up BID.MB.
      'G'  - Auto-GM.
      'O'  - Mark old messaged, kill old bulletins.
      'U'  - Create WP Update message.
      'E'  - End of Housekeeping event.

   'R' - RoundTable event. Generated by RT.EXE into RT.LOG.

      'E'  - End of RoundTable execution.
      'J'  - Station joined the RoundTable.
      'L'  - Station left the RoundTable.
      'S'  - Start of RoundTable execution.

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

The following provided by AD8I :

Contrary to MOST explanations, dropped characters are not due to DESQview
or other multi-taskers.  The problem happens for two reasons.  First, overrun
of the serial ports (eg. the TNC is sending data to the computer faster than
the computer can handle it).  Second, due to shutting off the interrupts.

All serial ports drivers commonly used by W0RLI and WA7MBL PBBS programs are
interrupt driven.  When the UART (normally an 8250 [XT] or 16450 [AT])
receives a character on the serial port, the following happens:

    1) the serial port issues a HARDWARE interrupt by raising one
       of the IRQ lines on the bus.

    2) the 8259 programmable interrupt controller sees the change
       in the IRQ and tells the CPU to stop whatever it is doing
       and branch to the code for handling the interrupt (MBBIOS).

    3) our interrupt handler (eg. MBBIOS) takes the character from
       the UART and moves it to a buffer area in memory reserved
       (by MBBIOS) for storing input until it can be processed.

    4) when the character has been moved to memory, the interrupt
       handler returns control to whatever was happening before
       the interrupt

When there are high speed ports on a ("slow") CPU, eg. mulitple 9600
baud TNC links to a 4.77 MHz V20 CPU,  it is possible, even likely,
that another characer will be received before the first has been
handled.  When this happens, characters are dropped.

Some disk caches (eg. VDISK) use EXTENDED memory in an AT (80286).
Due to the design of the 80286, these caches must disable interrupts
when moving data to or from the cache.

Most single character errors are of the first type while most multi-
character errors are of the second type.  NO amount of "tweaking"
the DESQview time slices will solve either problem since the serial
port drivers load before DESQview.  The port interrupts whatever
DESQview is doing to allow the serial drivers to do their thing.
In a VERY busy system DESQview (and the various MB tasks) will actually
come to a halt if there is too much I/O activity (both serial and
disk I/O).

There two approaches to solve the port overrun problem:

    1) Use UARTS with INTERNAL buffers.  For example, the 16550 is a
       direct replacement for the 8250 and 16450 with an internal 16
       byte (character) buffer that can be used by software designed
       for the purpose.  The 8530 HDLC chip used in the DRSI PC*PA
       includes a 4 byte buffer.

       MBBIOS, FBIOS and G8BPQ's ASYNC support (NET/ROM and KISS
       protocols) protocols could be easily modified to detect,
       enable, and use the buffer in the 16550 if the software
       writers chose to do so.

    2) Use TNCs operated in HOST mode.    In host mode, the computer
       polls each TNC for data at its own pace.  The computer can
       make use of the buffers IN THE TNC to hold data until the
       computer is ready to handle it.    When the computer is ready,
       it can empty the buffer on one TNC at a time.  (The AA4RE
       BB software uses this technique.)

The only way to solve problems caused by shutting off the interrupts
is to eliminate the EXTENDED memory disk cache.