Possibilities - More About TBBS 2.2

Contact:   eSoft, Inc. (Makers of TBBS)
           15200 E. Girard Ave., Suite 3000
           Aurora, CO  80014
           (303) 699-6565      Voice
           (303) 699-6872      Fax
           (303) 699-8222      BBS
           support@esoft.com   E-Mail

MORE ABOUT TBBS 2.2
-------------------

*** From June 1991 Possibilities Newsletter ***
*** Copyright 1991 by eSoft, Inc.  All Rights Reserved ***

More About TBBS 2.2
by Phil Becker

In the March issue I related some of my philosophy about why TBBS has the 
features it does and why it has evolved into what you see today.  I told you 
that TBBS 2.2 can be multi-lingual to the caller and that you can fully 
customize every piece of text in TBBS as a result.  I also indicated that 
TBBS 2.2 will have a 64 line version and that all versions will run more
users faster on the same hardware (as compared with TBBS 2.1) as a result.  
Finally, I touched on the fact that TBBS 2.2 will eliminate the 640k 
conventional "Ram Cram" which can be a problem for larger systems with TBBS 
2.1 and that you will be able to have thousands of message areas in TBBS 
2.2.

Since all software is shaped by the philosophy of its creator as well as 
demands of the marketplace, I also tried to give you my philosophical 
guidelines to help you see where TBBS is going and why.  This "taste" of 
what will be in TBBS 2.2 has unleashed a flood of requests to know more 
about what will be in TBBS 2.2.  While I am keeping most new features "under 
wraps" to avoid having TBBS 2.2 seem old the day you get it, this month I 
will give you a look at a few more things you will see in TBBS 2.2.

First let me say that a list of all the new features which will be in TBBS 
2.2, and all the new applications it will be able to address would not fit 
in this newsletter.  This doesn't mean it will do everything you can 
imagine, but it does mean it will be a very significant advance in 
capability and ease of use over TBBS 2.1.  I think that most items on most 
"wish lists" I have seen will be addressed -- at least partially.

Improved Q&A capability...

The Q&A function in TBBS 2.1 has remained essentially unchanged for over 5 
years.  The world has changed a lot in that time and this area of TBBS cried 
out for a radical overhaul to address today's online survey and voting 
requirements.  TBBS 2.2 will have a totally revamped Q&A capability.  QAEDIT 
is gone, and QAL (Question and Answer Language) will take its place.  QAL is 
very similar in structure and function to SDL but it is aimed at allowing 
you to create very sophisticated surveys and voting functions.  Since ease 
of conversion is always a major issue with me, a conversion program will be 
supplied which will convert all of your TBBS 2.1 Q&A files into QAL for use 
as-is on TBBS 2.2.

QAL will allow you to tailor the .SVY file output any way you wish based on 
the user's input.  In TBBS 2.1 the .SVY file format is fixed.  Many of you 
have expressed a desire to format that output exactly as you want it so that 
it can feed other programs more easily.  With TBBS 2.2 QAL you will have 
100% control over how the user's responses are formatted in the .SVY file 
and you can even add special characters or intermediate data lines to the 
.SVY file to assist you in handling the data later.

When handling input, QAL will allow you to specifically verify the format of  
input such as credit card numbers, social security numbers, dates, etc.  
Specific functions will even perform the check digit algorithms on credit 
card numbers and social security numbers to assure they are valid if you 
wish.  You will also be able to require certain lengths of input, specify 
multiple choice single character input with only certain valid responses, 
specify default inputs if the user presses return without any entry and 
handle errors specifically if that is important to your application.

QAL also allows you to place labels in your questionnaire and branch around 
certain questions based on input to avoid asking questions which make no 
sense based on answers to previous questions.  QAL allows you to define 
variables which can store answers for you to make decisions or use later.  
With regard to decision making, QAL also has a full IF ... ELSE ... ENDIF 
structure so you can control the flow of the questionnaire based on the 
user's responses.  And you can make these decisions not only based on the 
user's input, but also on the user's current authorization, privilege, and 
terminal profile characteristics.

One of the most exciting parts of QAL is that it will have a facility to 
allow you to ask multiple questions as a formatted screen if the user has 
ANSI active.  This will allow you, for example, to put a full name and 
address screen up and let the user cursor through it in a full screen 
editing mode to fill in the blanks.  If the user doesn't have ANSI set, the 
same screen will automatically become a set of individual TTY style 
questions so you don't have to handle both cases explicitly.

The TBBS 2.1 Q&A function only allows you to change authorization flags.  
QAL will let you change many more items such as privilege and user terminal 
configuration as well.  This will allow you to write custom new user 
terminal configurations if you wish as well as many more enhanced control 
functions.

With QAL all limitations on the number of questions or the size of the text 
in a question will disappear.  So each question can be a full ANSI formatted 
screen if you desire!  There will be almost no limit to the screen 
presentation capabilities Q&A will have in TBBS 2.2 with QAL.

Using QAL is simple too.  You just run your QAL formatted questionnaire text 
through the QAL compiler and it will generate .QAF files.  You then use the 
TYPE=32 command just as you do in TBBS 2.1 to invoke the resulting 
questionnaires online.  As with SDL you can put multiple questionnaire files 
in a single QAL source file, use the Include: command to organize them, and 
use macros if these are helpful in your application.

All in all you will find that QAL is very easy to use but provides you with 
the most state of the art Q&A capability available on any BBS software.  In 
many cases you will be able to write QAL questionnaire files which replace 
functions that can currently only be done by adding a TDBS program to your 
TBBS 2.1 installation.

ZMODEM-90(Tm)...

Callers to the eSoft support BBS have noticed that the ZMODEM menu selection 
is now titled ZMODEM-90(Tm) and have asked what this means.  What it means 
is that TBBS 2.2 will have the most complete ZMODEM implementation as well 
as the fastest available anywhere.  I have negotiated with Chuck Forsberg of 
Omen Technologies, Inc. (the inventor of ZMODEM) to license the rights to 
incorporate ALL of the proprietary ZMODEM features he has developed.  These 
extended capabilities are not part of the normal public domain ZMODEM 
specification and thus are not part of most ZMODEM implementations outside 
of those written by Omen Technologies.

TBBS 2.2 will be the first 100% assembly language implementation of ZMODEM-
90 which is the name OMEN gives to a ZMODEM implementation which contains 
not only the base ZMODEM but also the Moby-Turbo Overthruster feature, RLE 
data compression, quoted 7 bit and packed 7 bit capability.  This means that 
TBBS 2.2 ZMODEM will operate correctly over 7 bit links with a ZMODEM-90 
capable terminal program and do so at maximum efficiency.  It also means 
that a TBBS ZMODEM transfer with a ZMODEM-90 terminal program will transfer 
compressed files nearly as fast as YMODEM-g.  Note that these advanced 
features will only work with a terminal program which is also ZMODEM-90 
capable such as a registered copy of DSZ.  All of these extended features 
must be present for an implementation to earn the name ZMODEM-90 and TBBS 
2.2 will have them all.

Custom Parameter Insertion

As I stated in March TBBS 2.2 will allow you to customize all of the text 
and responses inside of TBBS itself.  However, the desire to customize goes 
beyond just re-arranging text itself.  TBBS 2.2 will have many "Insertion 
Parameters" which you will be able to use in text files and menus.  These 
parameters will be replaced with values when the text is displayed.

To demonstrate how these parameters work, let's look at some of them.  An 
insertion parameter is bounded by percent signs at the front an back of the 
parameter name.  The ones we will examine in this example are the parameter 
%Name% which is replaced with the full name of the current user, %First% 
which is replaced with only the first name of the user, and %Location% which 
is replaced with the caller's location.

  A sample text file which uses parameters might be:

Welcome to our system %First%.  In order to gain access to all of the 
features this system has to offer you will have to select the <R>egister 
option from the top menu and answer all of the questions.  If you do so 
honestly you will be granted full access immediately.  Remember that you 
logged on this time as %Name% calling from %Location% and you must use the 
same logon identification each time you call or the system will think you 
are a new caller.

The  insertion parameters will be replaced with the indicated items out of 
the userlog when this file is displayed so it is customized to the caller.

Insertion parameters may be used in questionnaires, menu text, text files, 
and other internal TBBS text strings.  If they are used in a file which is 
downloaded they will only be translated if an ASCII download protocol is 
used, they will not be translated if the file is downloaded with a protocol 
such as XMODEM or ZMODEM.  Insertion parameters may not be used in message 
headers or text.

There will be many insertion parameters available in TBBS 2.2.  These will 
allow you to create many custom statistics displays (such as time remaining 
in a billing class, authorization limits, download and upload byte counts, 
etc.) by simply making text files and displaying them with a TYPE=1 command.

Insertion parameters in TBBS 2.2 will be easy to use since they are all 
printable characters.  This means that any editor may be used to place them 
in text.  You may combine insertion parameters with ANSI colorization and 
IBM graphics characters to create many very attractive displays which are 
totally customized to both your system and the caller.

One side benefit of insertion parameters is that for many of you they will 
allow you to gain back several of your authorization flags.  It has become 
common to use some of your A3 flags to indicate line number, and some of 
your A4 flags to indicate baud rate.  With high speed modems and several 
lines, you can easily lose nearly all of these flags to this one function.  
With TBBS 2.2 you can use the insertion parameters %Line% and %BPS% for this 
purpose and regain the use of all of your A3 and A4 flags for other 
purposes.  As an example you could put the following line in your menu:

Calling on Line %Line% at %BPS% bps.

A caller on line 5 at 9600 bps would see this line as:

Calling on Line 5 at 9600 bps.

The insertion parameters would display with the proper current values of 
their respective parameters.

The combination of insertion parameters, the enhanced questionnaire 
capability, and the ability to default logon parameters will allow you to 
tailor the logon procedure exactly as you wish it for your application.

Enhanced Performance Monitor

TBBS 2.1 gives you a capability which no other BBS software provides, and 
most multi-user software doesn't provide -- the performance monitor.  This 
performance monitor gives you tremendous visibility into the way TBBS is 
loading your hardware while it is operating.  However the meters in TBBS 2.1 
only monitor the desired load of the software, they don't give you any idea 
of how the TBBS scheduler is delivering these resources to the user.

The missing item in the TBBS 2.1 performance monitor display is response 
time.  That is, how long do users have to wait to get service when they need 
it.  Response time delays is what users feel as "jerkiness" or "choppiness" 
in the system.  The Idle time meter is only an indication that TBBS does or 
doesn't need the entire computer to do the job the user has requested.  With 
TDBS programs and file directory and text searches it is becoming common for 
the idle time meter to indicate the entire system is used because the user 
has a long term task to perform and TBBS is supposed to use all of its 
resources to satisfy it.  What you really want to know is if the other users 
are still obtaining smooth rapid responses to their requests.

TBBS will add three new meters to the performance monitor which will 
indicate the response time delay in milliseconds for each type of task.  
These meters let you quickly see if users are seeing a system load or not, 
and that is what you really need to know in a large, heavily loaded system.  
These new meters give you information which is unavailable for most 
software, and extremely difficult to obtain even on mainframe and 
minicomputer operating systems.  It will let you know at all times how TBBS 
is treating your users, and where any performance problems you may have are 
rooted.

TBBS 2.2 Single Line

As I have indicated eSoft will cease selling single line to new users when 
TBBS 2.2 is released.  Our entry level system will become a two line TBBS 
2.2 which will sell for the old TBBS 2.1S price of $299.95.

I will spend the time and money to make a TBBS 2.2S but it will only be 
available as an upgrade to current TBBS 2.1S users.  If you now own TBBS 
2.1S you will have the option to choose to upgrade to either TBBS 2.2S or 
TBBS 2.2M[2] for the same price -- $75.

This has caused some confusion.  Some are asking "who would want 2.2S when 
they can have two lines plus the console for the same price?"  Others are 
asking "Is Phil going to abandon those of us who have to have TYPE 44 
commands?".  The answer is that I feel that most single line users will want 
TBBS 2.2M[2].  But I also know that some of you just can't abandon your TYPE 
44 commands and will require TBBS 2.2S.  That's why I am making a TBBS 2.2S 
-- just for you.

However it will be quite an effort to make TBBS 2.2S and it will ship about 
30 days later than TBBS 2.2M will since I am not going to delay shipping the 
multi-line version while the single line is finished and packaged.

I hope  this clears the confusion a bit.  All of my customers are valuable 
to me -- even if I can't always give them what they need.

- END -
PS0691-4
Rev. 6/91

Copyright (C) 1994 eSoft, Inc., All Rights Reserved.  Permission granted
to distribute this file in its entirety, without modification, to any
interested party.  Any other use requires the written permission of
eSoft, Inc.

IMPORTANT:  The information herein is subject to change without notice.
Please call or write to confirm factual information of importance to you
or your organization.

