The disk operating system used with this system is PC-DOS version 3.3

The Communications Software is The Bread Board System (TBBS) Version 2.1. It is
available from:

.                   eSoft, Inc.
.                   4100 S. Parker Rd. #305
.                   Aurora, Co 80014
.                   (303) 699-6565

Network mail capability is provided by SEAdog, v 4.1.  It is available from:
  
.                   System Enhancement Associates Inc.
.                   21 New Street
.                   Wayne, NJ 07470


>>> The Bread Board System Information Sheet<<<

     The Bread Board System is a fast, responsive, flexible system which allows
the owner to design his own format without having to write any program code. 
It also allows all of the advantages of a machine language coded system such as
speed and efficiency without the drawbacks of being difficult to modify. You 
are not locked into any  particular structure with this board and may make it 
look like almost anything you wish.

     Version 2.1S is an economical single line system, while Version 2.1M 
provides the power and speed of TBBS on up to 32 lines on a PC/AT or 80386 
class machine, using just PC-DOS.  Yes, that's 32 simultaneous callers on a 
single PC, using just PC-DOS, and at a response time degradation of less than 
10 per cent when all lines are fully loaded at 2400bps!  TBBS truly provides 
mainframe power on a micro-computer! (Better in most cases!)  With the addition
of the Network Mail option, TBBS can be FidoNet compatible (for store and 
forward mail handling between systems) as well.

          TBBS cannot be described in writing but we will try. Using it is an 
experience.  For the first time non-programmers can build a system to carry out
their communications ideas exactly as they want.  It is so easy to modify you 
cannot believe it until you try it.  It has power and speed which have never 
before been seen in the micro-computer world.

     What do we mean by fast?  The measure of system speed is how closely it 
approaches the ideal of being limited only by the data transmission rate.  TBBS
2.1 is the ONLY commercial system currently on the market which can truly drive
19,200bps. At 19,200 bps the data transmission rate is 1,920 characters per 
second.  This means that if you take a stop watch and time the transmission of 
a 192,000 character file it should take 1 minute 40 seconds if the system is 
running at the ideal rate. A TBBS system on an 8Mhz or faster 80286 computer 
will transfer this file in the theoretical minimum of 1 minute 40 seconds. On 
most other BBS systems available this transmission will take much longer, 
indicating failure to drive the serial data line at full speed.  What's more 
TBBS can deliver this throughput with several other lines running at the same 
time!! Many of the  other delays which appear as "jerkiness" in most systems 
are either non-existent or drastically reduced in TBBS.

       What do we mean by responsive?  TBBS accepts commands between each 
character printed.  On menu displays or command prompts you don't have to wait 
at all for even the end of the line.  Press the key, the command is executed!

       As to the matter of flexibility and NO PROGRAMMING. Surely we we must be
kidding here!  No!  For as amazing as TBBS is to operate when you call in to 
one, the SYSOP side must be seen to be believed.  The entire system is built 
using a series of editors. A TBBS system is structured in two operations. The 
main configuration editor (CEDIT) is used to define from 1 to 63 message 
boards, and from 0 to 25 terminal types for user configuration.  It also allows
configuration of system-wide options such as should users logon with a password
or by first name/last name.  Here also you choose the default privilege, 
authorization, and time limit given to a new user.  There are other items which
are defined here such as the sign-on message and several system features. You 
simply specify how each feature is to operate.  NO PROGRAMMING!

     After the main configuration is established the system command structure 
is defined.  Here is where TBBS leaves anything you have ever seen in the dust.
Using a menu editor program (MEDIT) YOU supply the menu text, menu structure 
and menu linkages in a simple to specify form. NO PROGRAMMING!

     TBBS is actually an interpreter for a highly specialized and easy to use 
"specification language" which allows you to "roll your own" system.  Thus the 
name.  You may "Bread Board" or experiment with new looks and designs extremely
easily. Call in the Editor, change the structure, run TBBS and presto the new 
structure is there!  You simply cannot believe it until you experience it.

       A system may have only one menu or as many menus as you have disk space 
for.  Each menu may have a title or not as you desire. The menu defines the 
commands available to the user. You define the text to be displayed to the user
for each command, the privilege and authorization level required to see and use
the command, and the command itself which this menu key character will invoke.

       TBBS provides commands which allow you to structure almost any system 
you desire.  If your system becomes too complex to fit in one menu you may use 
menus as "subroutines" up to 20 levels deep and may build either tree 
structures, threaded structures or a combination of both as required to do your
job.  TBBS supports up to 63 individual message boards. Each board may be 
optionally set up for E-MAIL, public messages only, or both public and private 
messages.  Each board may be configured in a variety of ways to present almost 
any appearance desired.  Boards may be totally hidden from un-authorized  users
or restricted and advertised to non-authorized users. Optionally some users may
be given read-only access to some or all of the boards defined in a given 
system.  The interplay between each board definition (done with CEDIT) and 
board access command privilege and authorization (done with MEDIT) causes each 
of these possible outcomes.

       Almost all of the text used to prompt the user may be defined in either 
a Menu Control File or the Configuration Control File.  This allows an 
unparalleled flexibility in tailoring the individual system to the SYSOP's 
desired appearance without requiring any re-coding of the program itself.  The 
overall system structure (what commands are available, to whom, in what menu 
levels) is TOTALLY defined in the Menu Control Files and thus can be changed at
will.  The system has no intrinsic structure which would force your board's 
"look and feel" in any direction at all.  Therefore each TBBS system will 
likely look and feel totally different from each other as it is structured by 
the SYSOP (with no program coding changes!!)  to serve its owner's exact 
requirements.

   For those who want more flexibility in system design, and don't mind some 
simple programming, Version 2.1 of TBBS provides the System Definition Language
(SDL) compiler.  This compiler allows you to use macros, source libraries and 
many other "programmer" features to build very sophisticated menu structures 
easily.  While you don't have to use it to get much of the power of TBBS, it 
allows you to go much further in system design than was previously possible! 
Combined with the many new features of Version 2.1 (such as internal events for
timed menu structure changes, Multiple file area control for single area 
presentation of up to 255 file areas as a single group with searching by date, 
file name, and/or keyword across all areas, The Keyword search Database 
capability to name but a few) SDL moves TBBS to an entirely new level of 
flexibility and power while maintaining ease of use to the non-programmer.

       Several system facilities provide for ease of structuring Help options, 
Downloading, Uploading, and other non-message handling board features.  These 
options allow implementing the features in almost any fashion desired with 
extreme ease.  These options are implemented and structured using MEDIT (or 
SDL).  The unlimited (except by disk space) extensibility of TBBS makes this 
truly a revolutionary communications tool.  TBBS will handle easily tasks which
other systems can manage only with extreme difficulty, a lot of reprogramming, 
or not at all. Remember that with TBBS a job can be divided, and as many menus 
as required used.  Also all features such as download, help files, etc. can be 
replicated as many times as necessary to allow the job to be broken down into 
categories and managed easily.  Q&A files allow any number (yes any number) of 
votes or interactive survey operations such as registering users, product 
ordering, software reviews, etc.  Constructing a survey or a vote is as easy as
calling the QAEDIT, typing in your questions, and placing a command line in a 
menu using MEDIT to run the Q&A function!

       The Menu Control file "language" has forty (40) command types which are 
grouped in categories and allow structuring of all of the available TBBS 
functions.  The system allows 255 levels of user privilege (0-254) with a 256th
level (255) reserved for full SYSOP privileges.  There are also 32 feature 
authorization flags to allow various features to be used only as the SYSOP 
desires.  These even allow the structuring of up to 32 "parallel" systems in 
which the users of each have no knowledge of or access to the others.  You may 
have a "front" system and one or more totally hidden "real" systems.  Also 
sections may be set up with a remote SYSOP authorized so that he has full 
control over that section only (adding bulletins, info files, stories, being 
able to read and delete all messages on only his board) while being unable to 
touch other sections.  An unparalleled capability in micro-processor based 
communications systems!

     If you've stuck with us this far, you may want to know just how all of 
this is done so easily.  Well the secret is in the editors.  Menus are created 
by typing in the text line and the authorization and priviledge along with a 
command type. Menu Control File commands provide the following capabilities:

1. Menu branching control.  This category allows menus to call each other and 
return under very precise control.  A menu may call another menu explicitly by 
name (equiv to the GOSUB function in BASIC).  This call will save the calling 
menu on a stack and the called menu may either RETURN or in turn execute 
another GOSUB. The stack holds the last 20 levels of nesting and so sub menus, 
like subroutines in BASIC, may be called from many places and set up to return 
correctly to their caller.  In addition any menu may return to a menu up any 
number of levels in the stack thereby skipping on the return any desired 
sub-menus.  Any menu may elect to branch directly to the top level menu and 
flush the stack for a total menu path abort if desired.  A GOTO menu command 
allows making circular or cross-linked structures at any nesting level if 
needed.  Thus TBBS allows for very intricate threaded menu structures if 
desired to service all types of system design and user needs.  And these 
structures may be created and typed in as fast as you can think them up.  When 
they are typed in to the MEDIT control file base, they are online and ready to 
go!

2. General system functions.  This category of commands allows for the 
following general system functions:

    o Re-configuring for a user terminal (nulls, LF, etc.)

    o Displaying elapsed logon time

    o Terminating a session (logging off)

    o Displaying the Userlog

    o Re-entering the logon process

    o Invoking the Chat mode

    o Changing the user's logon password

    o Changing the verboseness of the user's menu prompts

    o Breaking the board and exiting to DOS

    o Exiting to DOS and executing a specified DOS command with a warm start 
return to TBBS.  Including running a BASIC program to accomplish any function 
we left out of TBBS (single line only).

     Each of these functions is implemented as a single menu control file 
command so that the SYSOP may either include each of them or not in his system 
as and where desired with a single menu command file entry for each.

 3. File selection and display.  A group of commands concerned with displaying 
or downloading a specified file from the system disk data base to the user's 
terminal.  There are a total of 20  commands dealing with this function to 
allow almost any desired implementation.  The commands provide for the 
following functions:

    a. Display a single file.

    b. Display a file which gives a list of choices for files to be shown.  The
user is then prompted for a selection and the selected file is displayed to 
him.  He is prompted for more selections until he exits back to a Menu Control 
File.

    c. Keyword Search Data Bases with an index file which points to related 
files.  Searches may be made with multiple keys, and each database command can 
specify "And" or "Or" operation when multiple keys are used.  After the index 
lines are located, they may optionally point to any file you wish for more 
information. That file may either be displayed on the screen or optionally 
downloaded as the SYSOP decides. Each Data Base may operate in its own way, 
with any number of databases, and any combination of access methods required to
accomplish the task at hand.

    d. Display a partitioned text.  The user is given the choice of selecting 
all or part of the text work to be displayed.

    Each of these display methods is further qualified by whether the display 
is to be downloaded (allowing the user to select from the error resistant 
protocols listed below) or not and  whether the displayed text is to be word 
wrapped for best appearance on all terminal screen sizes or unwrapped for exact
data transfer.

   4. Upload/Download Control.  Along with several ASCII protocols, TBBS 
supports the following file transfer protocols:

   o XMODEM Checksum and CRC
   o YMODEM, YMODEM Batch, and YMODEM-g
   o SEAlink
   o KERMIT and SuperKERMIT

Several Menu Types allow maximum flexibility in  restricting the user's file 
name generation and overwrite capability control. They also allow Raw or 
Structured use with or without file descriptions and an intermediate Pseudo 
Directory and/or File Area List (to gorup several Pseudo Directories into a 
single File Area). Files may be made immediately available for download, or 
held for SYSOP review before posting.  They may be fully segregated to 
individual DOS subdirectories, or intermingled for maximum flexibility. Finally
files may be made "private" so that only the named caller can see or access 
them. Thus sub-portions of the SYSOP responsibility may be safely allocated to 
various persons and the total upload capability may be controlled as tightly or
loosely as desired.  On Download, Commands allow a wide variety of capabilites 
from RAW access to individual sub-directories, to fully buffered and protected 
Pseudo directory access with file descriptions in the directory and 
cross-directory transparency if desired.  In fact one file may appear in 
multiple pseudo directories if needed.

   5. Questions and Answers.  The Bread Board System also supports a flexible 
Q&A file function which allows easy structuring of either a secret ballot vote 
or individual "fill in the blank" type questions.  This function can be used to
implement user surveys, product ordering, or any other question and answer task
required.  Again, no programming is required to use this function.  A data file
is set up with the questions and type of answers and a single Menu Control File
command invokes the process. Another command allows viewing the results of 
secret voting online. In addition, features are provided to remove voting 
commands for a user's menu after he has voted, so a caller can only vote once. 
No stuffing the ballot box!

   6. Message Boards.  At last, yes there is also the traditional message board
function.  In fact up to 63 separate boards are supported. One or more may be 
configured as E-MAIL service while others may be presented as either combined 
or separate (or a combination of both) and set to allow private messages as 
well as public or only public messages.  Plus reply chaining allows developing 
conferences on a given subject topic within a message board.

To create and use a message board the following steps take place:

    a. Each board is configured (using CEDIT) with:

       1. A 1-16 character name (imbedded spaces are allowed) by which that 
board is known.

       2. Access definition. A board is either available to be accessed in the 
combined mode (in which case all messages come up sequentially from all active 
combined boards) or as only accessable by a direct access by name and 
un-available for combined access.  (All boards may be directly accessed if 
desired.)

       3. The privilege required to Read the board is specified.

       4. The privilege required to Write to the board is specified. This may 
be the same as read Privilege, higher (to allow some users "Read only" access 
to this board) or lower (to allow some users "Write only" access to this board 
as in MSG TO SYSOP function).

       5. The authorization flags required to access this board.  If none are 
specified, then access is by privilege only.  If any flags are set a user must 
have the same flag(s) set in his Userlog authorization field to access this 
board.

       6. The board type.  This may be E-MAIL or standard. If standard you may 
define whether or not private messages may be posted on this board.


    b. After defining the message board you then place board access commands in
a menu file using MEDIT:

       1. Read, Write, Delete, Scan commands are placed in any menus desired. 
The text by which the user sees these commands is defined at this time.  Thus 
they may look any way you like.

       2. Commands are direct if they name the board in the OPT DATA field.  A 
"direct access" command will access only the board specified by name.  If the 
board name field is omitted the command is a "combined access" command and will
access all currently active combinable boards.  A user with a privilege of 255 
(SYSOP) may combine any boards for which his authorization flags match.  Also a
user with privilege of 255 may access any private messages or anybody's mail on
board for which he qualifies.  This is to facilitate SYSOP review of the 
message base.  Any user may be given SYSOP privilege for one or more individual
boards by setting the appropriate flags in his userlog entry If the user's 
privilege is below 255 then the Jr. SYSOP will be able to read private messages
or mail, and delete anybody's messages only on those designated boards.  On all
other boards he will be governed by normal system security.

     Thus TBBS is much more than a mere Bulletin Board System. It is a personal
communications tool with incredible power. Its uses are limited only by your 
imagination!  If you are using an IBM PC/XT, PC/AT, 80386, PS/2 or compatible, 
it is the only system you should need for all your online message and file 
transfer requirements.


Plus!!! Version 2.1 has an Option module Interface to allow extensions to be 
sold as options in the future.  The first option module to be available will be
released in Summer of 1989.  This module is TDBS (The Data Base System) and is 
a dBASE III+ compatible compiler and integrated run time. This will allow up to
32 line transaction processing systems with better response than many 
mini-computer systems with the same number of lines can provide, on a single 
computer at much lower cost and complexity than any other method available. 
And with the nearly universal dBASE III+ programming language for ease of 
implementation and maintenance. Call eSoft, Inc. (303) 699-6565 for details and
pricing.

Couple all of this with the ability to interface lines to low speed modems, 
high speed modems, Hard Wired terminals, Data PBX lines, or X.25 PAD interfaces
in any combination, and you have the absolute state of the art in 
micro-computer communications platforms on which to build your applications.

For more information contact:

 eSoft, Inc.
 15200 E. Girard Ave
 Suite 2550
 Aurora, CO 80014
 (303) 699-6565

 10am to 5pm Mon-Fri (Mountain Time Zone)

Type Selection or L for list, 
P to set protocol, <CR> to exit: 



-- Information About This System --

(C)apabilities of the System   <---- New Users !
(D)isclaimer
(E)CHO Conferences:  What are they?
(M)ap of the system
(S)ignon Bulletin

(-) Return to previous menu             (+) Return to main menu
(G)oodbye                               (T)ime online

Command: c


Type P to Pause, S to Stop listing

 Diablo Valley BBS System Information

.<1> DVPC BBS Hardware Information
.<2> DVPC BBS Software Information
.<3> DVPC BBS System Protocol       <<<---New users should read!
.<4> Detailed Software Information  

Type Selection or L for list, 
P to set protocol, <CR> to exit: 3


Type P to Pause, S to Stop listing


           +------------------------+
           | TBBS System Procedures |
           +------------------------+

This section explains how TBBS handles the following features:

    o Auto-logon
    o File uploading and downloading
    o Message entry
    o Message retrieval

If you have never used a TBBS system before you should print or save to disk a 
copy of these instructions. They will help answer some of the more common 
questions asked about how to use TBBS.

                 +------------+
                 | Auto Logon |
                 +------------+

For Auto-Logon, TBBS sends your terminal an ASCII ENQ character (^E, or 
Chr$(5)) at the "First Name?" question. Your terminal software should respond 
to this by sending your log on in the following format:

Firstname;Lastname;City,State;password

Note that semi-colons separate the different fields.  TBBS can be configured to
ask for your FULL name or a user ID instead of asking for First Name and Last 
Name as separate fields.  If this system is configured that way, omit the 
semicolon between the first and last name since this is a single field.  Also, 
if this system is configured not to verify the calling location (which is a 
system installation option) then you may make your calling location in the 
example above a null field.  Thus an auto-logon string for a system configured 
for FULL name logon and no location verification would be:

Firstname Lastname;;password


              +-------------------------------+
              | Uploading & Downloading Files |
              +-------------------------------+

Transferring files between your terminal and TBBS is called uploading and 
downloading.  Uploading occurs when you send a file from your system "UP" to 
the TBBS system.  Downloding occurs when you have TBBS send a file "DOWN" to 
your computer or terminal. TBBS supports several different file transfer 
methods (protocols).  These are:

 o ASCII protocols
 o XMODEM (Checksum or CRC)
 o YMODEM, YMODEM Batch, and YMODEM-g
 o SEAlink
 o KERMIT and SuperKERMIT


Now lets look at each one in detail:

ASCII protocols
---------------
   These protocols should be used only if you cannot use one of the error 
resistant protocols provided.  These are included as protocols of "last resort"
for use with non-intelligent terminals or terminal emulators, and dedicated 
word processors etc.

1. Prompted ASCII Upload.  The prompt character is the '>' (greater than) 
character.  The reason for utilizing a prompt character is to allow a delay to 
occur when the system is writing to the disk.  The prompt will not reappear 
until the system is ready to receive the next line of text.  To use this mode 
your terminal software must stop sending after each <CR> (carriage return) 
until it receives the next '>'.  You terminate the upload by typing 'END'.  No 
input data line may be more than 255 characters long in this mode.

2. X-ON after <CR> Upload.  This mode is very similar to the prompted mode. 
Your terminal program must stop sending after each carriage return and wait for
an X-ON (^Q) to be sent by TBBS before continuing.  You terminate the upload by
typing 'END' on a new line.  The 255 character maximum line length still 
applies in this mode.  Again, you terminate by typing END after a carriage 
return.

3. X-OFF/X-ON Upload.  In this mode your terminal program sends characters 
until it receives an X-OFF (^S) from TBBS. Your terminal program then waits for
an X-ON (^Q) to resume sending.  It must ignore any other characters (except to
display them if desired) while waiting for an X-ON.  In this mode, there is no 
limitation on line length.  You still terminate this mode by entering END after
a carriage return.

4. ASCII with ^R/^T Capture (Download).  This method signals your terminal 
program with a ^R before the data starts, and a ^T when it ends so your program
can capture only the file.  Otherwise it is like the ASCII no control codes 
described next.

5. ASCII no control codes (Download).  TBBS will send the data to your terminal
with no halts.  Your terminal may stop the data at any time by issuing an X-OFF
(^S) if it needs to stop to write the data to disk etc. It then restarts the 
data flow by sending an X-ON (^Q).


XMODEM Protocol
---------------
This is the most widely available error resistant protocol used today in the PC
community. It was first used by the CP/M community.  Any terminal program which
supports this protocol may be used. There are two variations of this protocol 
known as CHECKSUM and CRC.  The difference is that the CRC method is more 
reliable at detecting errors. This method should always be used if you have a 
choice.  When Downloading, TBBS can automatically tell if you pick Checksum or 
CRC, while on Upload you will have to tell TBBS which method to use.

YMODEM Protocol
---------------
This protocol is essentially CRC XMODEM with 1024 byte (1K) data packets. Some 
terminal programs may refer to this as XMODEM-1K. This protocol cannot transfer
file names or exact file size, and YMODEM-Batch (sometimes called "True YMODEM"
should be used if you have a choice. YMODEM is much more efficient at higher 
modem speeds on lines that have relatively few errors.

YMODEM-Batch Protocol
---------------------
This protocol is the same as YMODEM except that it allows the file name and 
exact size to be transferred.  It also allows multiple file names to be 
transferred if you are in a sectio of TBBS where that is allowed. The transfer 
speed and characteristics of this protocol are identical to the YMODEM protocol
listed above.

YMODEM-g and YMODEM-g Batch Protocols
-------------------------------------
These protocols are variants of the YMODEM and YMODEM-Batch protocols described
above. The difference is that this protocol does not provide error retry, but 
expects the hardware link to provide this service. In return, it becomes a 
half-duplex protocol and if the link is error free, this protocol will provide 
the maximum throughput which is theoretically possible. It is generally for use
with high speed error correcting modems as it provides the fastest possible 
speed of file transfer in that case.  Do not use this protocol if the link is 
not error free (i.e. if MNP or other modem to modem error correcting protocol 
is not in use).

SEAlink
-------
SEAlink is a "sliding window" variant of XMODEM. It was developed by System 
Enhancement Associates, and overcomes transmission delays caused by satellite 
links or packet switched networks. It is a full duplex protocol and has a 
"window size" of up to 6 128 byte blocks.  This means that end to end link 
delays of up to 6.6 seconds (at 2400bps) will not slow down the file transfer 
speed.  For reference a delay of this size using regular XMODEM would make the 
transfer take seven times its normal time to complete.

KERMIT & SuperKERMIT
--------------------
All of the above listed protocols require a full 8 bit link to operate 
correctly. Also, they are primarily supported by PC terminal programs, and are 
often not available on mainframes and minicomputers.  KERMIT was developed at 
Columbia University and released into the public domain in order to address 
these problems. A version of KERMIT as a terminal program is available from 
Columbia University for almost every micro, mini, and mainframe in use today.

This protocol will "negotiate" the link characteristics and adjust 
automatically to 7 or 8 bit data and to other features which may or may not be 
available on all implementations. It is also "friendly" with packet networks of
all types, since it guarantees that no control characters will ever be sent 
which the link may try to respond to. The TBBS KERMIT implementation will 
support such optional KERMIT features as Data Compression, 8th bit quoting, and
Sliding Windows if both the link and the calling terminal program will support 
them. TBBS does not support the GET "server" command, but uses the RECEIVE mode
instead.

SuperKERMIT adds sliding windows to eliminate link delays.  SuperKERMIT will 
automatically negotiate its way back to regual KERMIT if your terminal program 
does not support SuperKERMIT. SuperKERMIT provides a window size which is large
enough to eliminate the effect of end-to-end link delays of up to 23.5 seconds 
at 2400bps, or almost 6 seconds at 9600bps.


              +--------------------------+
              | X-ON, X-OFF Flow Control |
              +--------------------------+

TBBS supports X-ON, X-OFF flow control at all times when it is sending you 
data.  At any time you may transmit the X-OFF (^S) character and TBBS will 
instantly stop sending you output.  Send X-ON (^Q) to resume data flow to you. 
This allows your terminal program to stop character flow while it spools to 
disk anything you are saving.  It also provides a means of manually stopping in
Menus and other areas where the 'P' for pause feature will not work.


              +-----------------------+
              | FULL DUPLEX OPERATION |
              +-----------------------+

TBBS operates in a full duplex configuration and is always looking for command 
input when it is sending output to you. This means that you do not have to wait
for a menu to finish listing to give your next command.  The command will be 
acted on after the next letter is printed on output.  During Message or Text 
file output (such as this) the 'P' key will halt after the next character 
transmitted. When in this pause state a carriage return <CR> will resume with 
the next character, and an 'S' will abort the rest of the printout. Menu 
commands are always one character and do not require a <CR>.


              +-----------------------+
              | MESSAGE ENTRY METHODS |
              +-----------------------+

TBBS supports two forms of message entry.  These are the line mode, and the 
"Off Line prepared text" mode mode.  The line mode is intended for manually 
typed in messages (the most common type).  It prompts for each line of input 
(you have three options on how that prompt appears based on your setting in the
reconfiguration section).  The "Off Line prepared text" mode allows you to use 
one of the file transfer protocols to upload a file you typed off line into the
message input buffer. When you have entered your message you will be given a 
set of options as follows:

<L>ist, <V>iew, <C>ont, <E>dit, <S>ave, or <Q>uit?

<L>ist displays your entered text without word wrap and with each line 
numbered.  The numbers are used for editing if you wish, or you can edit by 
strings as described below.  Remember that TBBS will word wrap your message 
when it finally displays it so the lines may not come out exactly as you expect
them.

<V>iew displays your message with word wrapping applied.  This allows you to 
see how it will look when it is read back.  Then if you need to you can edit it
until it looks like you wish.

<C>ont will place you in the line mode at the end of your message so you may 
add onto it.

<E>dit will ask you for a line number or /string.  You now have two options for
editing.

1. Enter the number of the line you wish to change (as shown by <L>ist) and 
that line will be displayed. You may then either re-type just this line as you 
want it to be or enter - followed by a <CR> to delete the line.

2. Enter a / followed by a search string (note you do not need to enter the / 
if the string is not all numbers.  This is the usual case).  TBBS will then 
prompt you for a string to replace it with. Enter either a new string, or <CR> 
to tell TBBS to delete the string.  TBBS will then display the first occurrance
of the string in your message, along with up to 15 characters preceeding it, 
and ask if this is the one you want to replace. Answer Y if it is, and the 
replacement will occur.  If it is not, answer N and TBBS will find the next 
occurrance of the string for you and display it.  You may continue in this way 
until it finds the one you meant.  If you want to quit, press "S" and TBBS will
abort the replace operation.

<S>ave will save your message to the system's disk message base and exit back 
to the menu.

<Q>uit will prompt you with:

QUIT (Y/N)?

If you press N, you will be returned to the prompt line.  If you press Y, TBBS 
will give up on entering this message.  All text will be thrown away and you 
will be returned to the menu as if you had never done the enter message command
in the first place.

Optional Prompts
----------------

If you are Authorized for file enclosures on this message board, you will 
receive one more prompt in the line.  This will be:

<F>ile

If you select this option tbbs will first ask:

Do you want to enclose a file in this message (Y/N)?

If you respond N, you will be returned to the prompt line with no action taken.
If you respond Y then TBBS will prompt with:

Enter the 1-12 character file name:

You may enter the name of the file.  This does not have to be a DOS legal name,
but may be any 1-12 characters you wish.  After you have entered the file name,
TBBS will prompt you to select your upload protocol exactly as described above 
in File Upload.  You upload the desired file.  After the upload is complete, 
the message

*Enclosed file xxx

Where xxx is the name you gave, will appear every time the message is read. 
The file may be retrieved by anyone who can read the message as described 
below.

If you are Authorized for Return Receipts on this message board, you will 
receive one more prompt in the line.  This will be:

<R>cpt

If you press this key, TBBS will ask if you wish to have a return receipt 
generated when this message is read. If you answer yes, TBBS will send you a 
return receipt message when this message is read by its recipient.


              +---------------------------+
              | MESSAGE RETRIEVAL METHODS |
              +---------------------------+

TBBS supports a variety of retrieval methods to allow you to quickly access the
messages you wish.  The methods are split into forward and reverse based on 
message numbers, and selective which is based on the Subject or who the message
is to or from.  In addition you may elect to pause after each message and be 
given an option to reply to each message or if you are after speed (say you are
calling long distance and spooling the messages to disk for later reading) you 
may elect to have all messages displayed with no pauses. In either case you may
pause with either a CTRL-S or the "P" key.  The retrieval options are:

1. Forward.  You are asked for a starting message number and all messages on 
the selected board(s) with numbers equal to or higher than the specified one 
will be displayed.

2. Reverse.  Same as forward except the display proceeds in reverse from the 
number you specify towards the first message in the system.

3. New messages. This causes a forward retrieval of messages which have been 
left since your last time on the system.

4. Marked messages.  This causes a display of any messages which have been 
marked in ascending numerical order.  A message may be marked by either using 
the Mark option on a scan, or by the automatic message waiting notification at 
logon.  Marks remain for the entire logon and go away when you log off.

5. Individual message.  You specify a single message number and if the message 
exists on the selected board(s) then it will be displayed.

6.  Selective retrieval.  You are asked if you wish to select by <F>rom, <T>o, 
or <S>ubject.  After you pick one, you will be asked for a text string to 
match.  This string may be a partial one and any message which contains the 
specified string in the specified field will be displayed.

Example: If you specify <S>ubject and a text string of IBM-PC then the 
following subject fields would all match:

IBM-PC USER'S GROUP ALL IBM-PC MOD I OWNERS IBM-PC/AT OWNERS

The string will be searched for anywhere in the specified field.  After the 
string is specified, you will be asked for a starting message number so you can
restrict the search time if you wish.


Pause between messages:
----------------------

On all retrievals except individual, you will be asked:

Pause After Each Msg(Y/N)?

If you enter Y then after the text of each message is displayed the prompt

<A>gain, <R>eply, <N>ext, or <S>top?

is always displayed.  There are other variable prompts which may also appear in
this line as described below, but these four are always present.

<A>gain - Pressing A will cause the message to be read again.  This read will 
not add to the "time read" count however.

<R>eply - Pressing <R> will allow you to enter a Reply to the message you have 
just seen displayed.  This reply will be chained to the message for future 
retrieves.

<N>ext - Pressing either N or <CR> will display the next message in the 
retrieve.  The N key is always active, even during the display of the message 
header and text.

<S>top - Pressing S will stop (abort) the retrieve.  This key is also always 
active, even during display of the message header and text.  Note: If you are 
reading a reply chain (described below) pressing S will take you immediately to
the End of Replies question and not all the way out of the retrieve.  Pressing 
it again will abort the entire retrieve.  This allows a quick way out of a 
message chain without stopping the entire retrieve process.

Optional Prompts
----------------

There are several optional prompts which will appear on the pause prompt line 
as appropriate.  These are:

<F>wd - If a message is addressed to you, then this prompt will appear if the 
system is configured to allow message forwarding. If you select it, you will be
asked who to forward the message to. Type in the name, and To: field will be 
changed to the name you selected.  If the message is private or EMAIL, the name
will be verified to be in the Userlog, and if it is not, you will be prompted 
to accept it anyway or change it.  The message will be marked as not received, 
and linked into the new user's message waiting list so he will be notified of 
it at logon.  If you don't wish to change who the message is to, just press 
enter.

After the name change prompt, you will be asked to enter the board you wish to 
put the message on.  Just press enter to leave it where it is, or select a 
letter from the menu of eligible boards displayed.

<D>elete - If a message is either from you or to you, this prompt will be 
displayed.  Press D to delete the message.

<E>ncl - This prompt will display if the message has a file enclosed in it. The
file name will also be displayed on a line above the prompt line.  Press "E" to
enter a download sequence (identical to normal file download as described 
above) to receive the enclosed file.


Reply chain reading:
--------------------

If the message you are paused at is part of a subject chain, then one or both 
of the two message chain prompts may be displayed. These are:

<*>replies  and <->

If you press *, you will get the next message forward in the reply chain.  If 
you press -, you get the message this message wa a replye to (backward in the 
reply chain).  Further, the meaning of the <N>ext prompt now changes to 
indicate the <N>ext message forward on the reply chain.  At the end of the 
chain in the forward direction, you will receive the message:

End of replies, add yours (Y/N)?

If you press Y, you may enter a message which is added to the chain. If you 
press N, the next sequential message which was not part of the chain is read, 
and the <N>ext command reverts to its normal meaning.

Since the * command is fairly subtle, it is used as a short cut.  If you press 
<N>ext on a message which is part of a chain, you will be prompted with:

Message has replies, read now(Y/N)?

If you enter a Y,  It is the same as pressing the * at the prompt line. If you 
enter N, then the next sequential message is retrieved.

Note: The replies which are displayed as a result of a chain read will not be 
displayed again during this retrieval.



No Pause between messages:
--------------------------

If you answer N to the Pause question, then the above prompt will not be given 
after each message.  You will be prompted for a reply, however, if the message 
is addressed to you and you have not read it at least once before. Also if a 
message is either from you or to you, you will be given a chance to delete it 
every time you read it.  This is to remind you to not leave old messages on the
system after their time as they take up valuable disk space. Note: Both of 
these prompts are under the SYSOP's control to configure.  So they may or may 
not occur for you.  When you select N to the pause question you will further be
asked:

For reply chains: <1> Ask on Each <2> Always follow <3> Never follow <?> for 
help

If you select 1, then every time a message is encountered which is part of a 
chain, you will be asked:

Message has replies, read now(Y/N)?

Answering Y, will read all related messages in order before proceeding with the
next message, N will read messages in strict numerical order.

If you select 2, the messages will always be retrieved by subject group, while 
3 will always retrieve in strict numeric order.

Note: Even in the No Pause mode, you may still press the N key at any time to 
get the <N>ext message immediately and the S key at any time to <S>top the 
retrieve.