
Ŀ
     _/_/_/_/_/_/_/ _/         _/_/_/_/_/ _/        _/ _/_/_/_/_/ _/_/_/_/_/ 
    _/    _/    _/ _/         _/      _/ _/_/      _/ _/             _/      
   _/    _/    _/ _/         _/_/_/_/_/ _/  _/    _/ _/_/_/_/       _/       
  _/    _/    _/ _/         _/         _/    _/  _/ _/             _/        
 _/    _/    _/ _/         _/         _/      _/_/ _/             _/         
_/    _/    _/ _/_/_/_/_/ _/         _/        _/ _/_/_/_/_/     _/          

  Ŀ
   MLPNet is owned and operated by Jim Coleman, Cherokee Production Studios 
  
                 "Onward to the 21st Century . . . and beyond!"
         ķ
          Dedicated to the sustaining influence of William A. Velez 
         Ľ
            MLPNet: (21:111/0, 21:111/1)       FIDONet: (1:350/111)
                         coleman@pacific.telebyte.com


         A CONDENSED REPRINT of an article that appeared in DSNEWS33.ZIP
      Permission granted to repost in any forum, but do not change contents.


Ŀ
Ŀ  Ŀ   Ŀ   
          ڿ      Ŀ     Ĵ Ĵ    Ŀ Ĵ ڿ  ڿ     
                      Ĵ              
      Ĵ Ĵ    Ŀ      Ĵ Ĵ        Ĵ ڿ  Ŀ
 Ĵ                                     ڿ       
           ٳ
                                                           
                       ܱ                          
                      ۱۳                         
                      ۱۳                         
                       ۱߲                          
 Sysop: Jim Coleman      ۲ܲ          MLPNet:  21:111/0 
 Co-Sysop: Scott Berry              FidoNet: 1:350/111 
                                                           
 No Alias Names permitted     coleman@pacific.telebyte.com 
                   ܳ߰    ܰ                      
  /\     
       
                    /\           /\           /\                       
                                                             
                             İ                                


NOTE, PLEASE NOTE:  Everything presented here is written from an "AT
THE TIME OF THIS WRITING" basis.  Keith and crew are working hard to
produce a bug fix version, promised several days ago, as usual.
Some of the problems delineated here may well be fixed by the time
you read this (but I wouldn't bet any money on it.)  This review is
not intended to slander any individual or entity; these are personal
observations and opinions formed after using ARI's KBBS software for
eight months, or so.  They are presented so that current users of
this software might understand better why some features work (or
don't work) as they do, and so that prospective ARI customers can
evaluate features of this software when making purchasing decisions.
Keith Anderson was notified in advance that this review was
forthcoming.   This review was written in its entirety by Jim
Coleman, and permission is granted to distribute or post this
material in other forums, so long as changes to the text are not
made.  (c)1995, Jim Coleman, all rights reserved.

PREFACE:

     KBBS, a product of Anderson Research, Springerville, UT, touts
itself as being the "fastest growing BBS software in the U.S. and
Europe."  ARI also makes the claim that KBBS is the most "powerful
and customizable BBS software in the world."  Where I may question
the validity of the first statement, the second may well be true.
Its proprietary SEQ language and unique memory management cannot be
matched (at least, not with anything I've tested) and a separate
Sysop Utilities menu makes configuration a snap. The problem is, it
barely works like a BBS should.

     I registered KBBS only after making certain its creator, Keith
Anderson, understood precisely what kind of system I ran and what I
expected out of my software.

     This was all very important to me: the system was a secondary
source of income (it helped keep us afloat during the 14 months I
was out of work after being hit by a car) and our MLPNet network was
bringing in 2000 to 3000 messages a month at that time. We had many
national and international nodes, we were frequently written about
in national and local periodicals and I made dozens of new sysop
friends and acquaintances from all around the country.

      Now, however, the system doesn't bring in revenue to cover the
cost of even one node, our nodelist contains a lot of inactive nodes
and NO international nodes, local sysops just sit back and get a
good laugh as my message pointers wipe out over and over again and I
see once-familiar names on other systems, but not MLPNet.  What
happened?  What changed?

      The software changed, and changed MLPNet with it.  But not
productively, unfortunately.

      Here are my opinions on KBBS, carefully formulated after many,
many months of use and literally hundreds of complaints and dozens
of compliments by MLPNet users.  I am very familiar with the
structure of KBBS and with its proprietary SEQ language, and that is
why I can claim that this is an "official" review.  No, ARI did not
request or authorize this review, but they are aware of it. I'll
start with what I like about KBBS (and what you will too!!!) and
then progress to what really cripples my system (and may cripple
yours as well, until fixed. But don't worry, it's ALL coded in and
just waiting for Keith to link in. [sarcasm intended].  More on that
later.)

       Besides, this whole review has been written for weeks, months even.
Let's link it all in.  If you don't like what you read here, don't worry,
you're the only one.  Everyone else loves it.  At least, that's what
Keith tells me about KBBS . . .

THE PROS:
FIRST, IT IS IMPERATIVE THAT I POINT OUT that many of the problems I
will delineate here are often pervasive in ALPHA VERSIONS.  Let me
explain this, to those who aren't as computer literate or familiar
with computer programming. An ALPHA VERSION is a developer's version
that is USUALLY tested on HIS OR HER MACHINE ONLY.  Keith Anderson
has been kind enough to allow the public to test his alpha versions,
to help with the bug fixes, etc.  A BETA version is released later
to the general public to accomplish the same thing.  Then, a RELEASE
VERSION is made.

When I address specific concerns, please remember that they are
sometimes from ALPHA VERSIONS.  Most specific concerns I list here
have been around for a long time, meaning they have also been
present in so-called "RELEASE" versions, as well.  I wouldn't target
anything in this forum that was confined to Alpha versions ONLY.  I
try to be as specific as possible with time frames and problem
longevities in fairness to Keith and the ARI staff. Additionally,
there is no way I can cover EVERY aspect of KBBS (good and bad) so a
lot of features that DO work and work well have not been mentioned,
since they work so well or are of no interest to me.  For instance,
I don't give a RIP about RIP, so there is no mention of KBBS RIP
capabilities outside this disclaimer.  I don't know if RIP works, if
it works well or if it works poorly.  However, if all that follows
is any indication  . . . )

SETUP:
I'll never forget the day I first unzipped KBBS and set it up on my
486 notebook machine to evaluate it. To be honest, I didn't expect
much. When I set it up on the hard drive, I was not prepared for
what I found.  The software LOOKED marvelous! The Sysop Utilities
Menu was a thing of beauty (fortunately, I didn't have a color
screen on the notebook, but a new color selection menu has since
been added). With an option bar across the top and multi-tiered
pull-down menus and some internal documentation with most options, I
couldn't help but start setting it all up right on the spot.  I ran
the computer around to coworkers who wouldn't know BBS software from
Benny Beanfart's favorite bass lure . . . but they shared my
enthusiasm. This was IT, my TICKET OUT OF HERE, I thought,
concerning CDC.

I came home, cancelled my subscription to "Salt Aire BBS" and set up
KBBS. A fund raising effort was started to register KBBS, but I got
in a hurry and registered it out of my own pocket.  Once the
registration key arrived, I sent PCBoard to cyber-hell and went
online with KBBS, to the exasperation of many.  I lost most all of
my callers right away, but I expected that.  No one likes change.
Most of the local ones came back.  Most of the long distance ones
never did, for reasons I'll explain later.

You want software that is easy to set up?  Well, don't expect any
documentation, but if you are reasonably proficient with your
operating system and BBS features (QWK, FTS, etc.) you can have KBBS
up and running in a snap.  I did, and I'm just a stupid,
inexperienced sysop.  More on that later, too.  :)

FLEXIBILITY:
Another exciting thing that attracts a lot of new callers to KBBS
(and might even attract YOU!) is that KBBS can look like (and even
emulate, to a degree) other popular BBS platforms.  You can make
your BBS look and act like PCBoard, WildCat!, Renegade, etc.  Brian
Schulties, a local Port Orchard area sysop, has done a REMARKABLE
job at making KBBS look and act like a Renegade system. He gives you
an option at login to display PCBoard menus or Renegade.  Well done,
Brian.  His number is 360-876-7958 if you need an example of what
you can do with KBBS.  Call me and (provided I'm still running it)
compare my setup to his.  There's no comparison, but it's the exact
same software.

SEQ:
Well, SEQ is the ONLY REASON I have continued to run KBBS.  It is
the only thing of any value KBBS has that other BBS software
platforms don't have and it is powerful and flexible (now that Keith
has graciously accomodated my early requests for array structures,
etc.)  PCBoard and WildCat! have their own proprietary languages and
I have done extensive programming with each, but none offer what SEQ
offers in terms of memory management, etc.  KBBS is by far a better
driving engine for SEQ than PCBoard is for PPE, though I understand
CDC is making remarkable strides in that area.  They've got a way to
go before catching up to SEQ, though.  Like I said, it's the ONLY
reason I'm running KBBS.  I began writing programs in SEQ to help
compliment KBBS and help promote it, but ARI apparently didn't need
any help so I started writing them for profit.  I've made it known
to Sysops who've registered my games and programs that I will
continue to support them no matter which way we go, just as I
continue to support my PPE programs when requested to do so.  I'm
working very hard now to write my own door frame and comm routines
so I can market my games and programs to ANY sysop running ANY BBS
program. Once I learn this (I don't claim to be an expert programmer
by any means, but it's amazing how fast you can learn if you apply
yourself) I won't need SEQ any longer.

THE CONS:
KBBS--The BBS software for those who love to wake up to a DOS prompt!

POINTERS:
One persistant problem with KBBS is message pointers.  This is a
problem that has plagued this software throughout the eight months
I've been using it as a platform for MLPNet Central.  Like a
bothersome intermittent drive train noise on a vehicle, the problem
comes and goes and (so Keith has claimed) is sometimes absent on his
system, even though numerous others are affected.  Two recent
messages stated that:

 "Since we've finally been having the last read pointer problem
start happening on Megalopolis instead of just everywhere else,
we've been able to run a debugging version of KBBS on Megalopolis
and we should have it fixed in the morning."  (If it was, we never
saw it.) Dated 07-25-95

 "After a week of running diagnoses on this and a few other
machines, and getting files from several sysops having pointer
setting problems, we have FOUND THE PROBLEM.  It's not a file-level
problem, and it wasn't even a problem in the pointer update code,
but a bug in the multitasking kernel not launching the update code
when it was supposed to.  This has been FIXED for tonight's
release." (Not released.) Dated 07-25-95 AFTER the preceding one.

True, this problem has been intermittent. One RELEASE version will
be so dysfunctional that you have to revert back a few Alpha's to a
more stable platform . . . and the problem doesn't occur in the very
next version.  But the one after that has the same problem.  It is
obviously a difficult problem and the ARI programmers have
undoubtedly expended a great amount of time to find a fix, but
there's a pattern of failure here that a sysop considering this
software may want to make note of.

CORRUPTION:
A huge problem KBBS has had since the first day I ran it is
corruption. I would imagine Keith would say it's normal and to be
expected, since he built in so many "Rebuild this, that and the
other thing" functions into the Sysop console.  Just by looking at
your Sysop menu, you get a REAL BAD FEELING with all the "fixits" in
place.  At first, I rationed away that bad feeling by thinking, "How
nice!  He's got everything in place here in the unlikely event
something gets mysteriously corrupted."  It took no time at all to
realize that important configuration and data files DO get corrupted
in KBBS, and it happens over and over again.  I've uploaded numerous
corrupted items to Keith in the past (file trees, message bases,
user records, etc.) for his crew to analyze.

"Defrag your disk more often" is something he once said.  This was
after I COMPLETELY reinstalled KBBS onto a newly reformatted hard
drive the week before.  There is a propensity at ARI to blame KBBS
problems on the Sysop without stopping to think it might actually be
a design flaw on their part. But, more on that later.  On the
subject of corruption, I've heard (on more than one occasion) "It's
only happening to you.  I can't explain it, Jim, but no one else is
reporting this."  Then, frequently, a fix is found a week or two
later and a celebratory message is written in ARI_KBBS about how the
problem "several sysops were experiencing" has been fixed.  Is
"several" half their registered sysops, three quarters of them . . .
or just me?

I never ONCE had a file corruption problem with PCBoard.  Enough said.

CHAT:
In all fairness to the ARI staff, there was no NODE CHAT option available
when I registered KBBS and I was told it would be "awhile."  I was content
with that and so were my callers until ARI made it widely known that NODE
CHAT would be coming in the next version.  That was months and versions ago
and it's still coming in the next version, I suppose . . . though they're
not being as vocal about its release.  Last I heard, it was being tested
at several remote sites.  I just figure it's one of those "it's already
written, just waiting for me to link in" kinda things.  I think I recall
reading somewhere that all the KBBS executables and overlays already
contain working node chat code, they just hadn't linked in or released
the SEQ routines needed to implement it.  This is one of those "I think I
read this" kinda things that I probably DID read at some point, but didn't
save.  Right now, NODE CHAT isn't a real concern with me as there's so many
"runnability" issues pending.

DOCUMENTATION:
 It's coming. It's been coming for a long, long time and talked
about often, and asked for almost DAILY in the ARI_KBBS conference.
ARI recently released a VERY WELL DONE SEQ Manual, after promising
(literally PROMISING) it to me several months ago.  "In a few days,"
Keith said.  That was back in April, possibly even March.  This was
back during early development of 'SCRAPER, my newest (and possibly
last) KBBS SEQ game. Good job, guys. REALLY appreciated the manual,
even though:

(1) it was released in a WordPerfect format I said long ago was
virtually worthless to me and
(2) it's far too late.  Better late than never, I suppose. Need
a slogan?

SCREEN COLORS
If you like to use color codes in your message base, forget it.
Head to your nearest software store and buy virtually any other
brand of BBS software.  KBBS won't remember a screen color from one
screen to the next. This is something I've bugged Keith about for
over half a year.  In fairness to Keith, I can't remember him ever
saying "it's coming." Maybe he knew that THIS time it really WASN'T
coming, so why build up false hopes?  It's such a simple thing,
really, but has become my focus and ANYTIME KBBS's RELIABILITY comes
up in discussions I have with other sysop friends, I mention the
fact that KBBS doesn't remember screen colors and the programmers
have known about it for a LONG time.  Again, if you are seriously
considering KBBS as your platform, remember this: this "little"
thing is very important to me and they know it, but nothing has been
done to correct it.  How huge does a problem have to be before it
gets upgraded to the infamous, extremely overused "it's written,
just waiting for me to link in" status?  (Which usually means:
sometime next season, if you're lucky.  If you're not Jim Coleman,
because it won't work for you anyway, even though it will for
everyone else. So get off your damn high horse, it's not my fault
you don't make backups and why don't you defrag your hard drive more
often STOOOOOOOOOOOOOPID!)

RECYCLING
Some versions (yes, RELEASE versions) haven't recycled properly (or
at all) when a caller hangs up or an event (internal or external) is
run.  This problem, as I understood it, was at first confined to
systems operating under one operating system, but was later expanded
to several operating systems//multitaskers, including Desqview and
OS/2.  This, like the message pointers, is a problem that seems to
come and go at random intervals spread out over many releases.
Unlike the pointer problem, however, it wears a different face each
time.  The release I am running now (1816) STILL has the problem
following an event.  Weirder yet, it displays the ROBOCOMM exit
screen after running an event <?????>, generates an error message
and either (1) drops to the DOS prompt or (2) recycles "normally."
This problem has persisted through three alpha versions now. Again,
it is something ARI has been aware of, and I fully expect to see the
same problem after the next alpha is released.  I hope they can
prove me wrong.    (THEY DIDN'T PROVE ME WRONG.  vZ1817--which was
released AFTER DSNEWS33 still shows the RoboComm screen on recycle.)

KBBS has not operated "reliably" in as long as I can remember.
There have been periods of time with one alpha or another where the
board was somewhat stable, but getting up five or six times a night
to reboot the system was--at one point--a nightly ritual that lasted
for many weeks. Even now, we STILL have to boot up nodes in the
middle of the night, when coming home from work, etc.  Something to
think about if you are one of those who expect to run a stable
system that answers the phones when you tell it to.  On the other
hand, if you are shopping for a program that closes down your
windows and basically shuts down your computer at random intervals
throughout the day and night, KBBS is for YOU!

ATTITUDE AND COOPERATION:
ARI needs a serious attitude adjustment, in my opinion.  Of course,
I read mail every day from people praising Keith and crew.  Keith
even forwarded me a letter one time that someone else wrote in
praise of them, just to try to prove me wrong, or something. I never
did quite figure out what his intentions were.

In the beginning, ARI was as helpful as could be.  I made many
suggestions and many SIGNIFICANT changes were made.  At one time,
Keith thanked me, saying that they were writing something THEY
thought the public wanted, but I came along and showed them what the
public REALLY NEEDED.  These changes are too numerous to list and I
wouldn't be running KBBS today were it not for them.  I am grateful
for the early cooperation and efforts.

However, as things seemed to unravel and become more unstable with
each release, the "newness" began to wear off and I came to realize
I possibly paid for something I was not gonna get in time to salvage
what remained of MLPNet.  Anytime you change platforms, you are
bound to lose some people, as (1) people are inherently resistant to
change and (2) most MLPNet callers are long distance and there is a
tremendous amount of setup work to be done before mail can flow
freely again.  Some didn't want to invest that time, some didn't
want to learn new scripts or new ways of doing things, but MOST WERE
FTS NODES and we had to wait a LONG TIME for FTS to be implemented
in KBBS.  To this day, our international nodes can't call since KBBS
won't properly gate MLPNet to them. This was something Keith told me
a long time ago would be a PRIORITY "so you don't have to
restructure your network or lose any more nodes."  Well, Keith,
thanks to your weird definition of the word "priority," we lost them
all. One node from Germany still calls routinely to see if there's
any mail, but KBBS doesn't recognize his node number, though it IS
in the nodelist and it IS in the gate setup.  At any rate, we've not
recovered from the NINETY PERCENT of FTS MLPNET nodes lost as a
result of no (or poorly working) FTS.  Current FTS nodes still
cannot utilize some areafixing and other standard features QFront,
Front Door and other established, stable front end systems can.  I
can not talk to some other FTS systems, and mail is choked off at
the source.  (1:350/0, remember that one, Keith?)

As I started seeing similar things going wrong, I began to get a bit
more vocal about them.  After awhile, they stopped listening.  Mary
and I played a little game sometimes:  "Okay Mary, here's a letter
where I'm telling Keith something is screwing up and I need it fixed
ASAP or we're gonna be in trouble.  Betcha we don't get a response."
and "Okay, here's a nice letter full of bubbles for something they
fixed."  Nine times out of ten, the bubbly letter got a response and
the other didn't.  In fact, there were several crucial messages
"lost" due to "hardware."  You'll see that critical mail regarding
THIS REVIEW was apparently "lost" due to the same reason.  I mention
over and over again in this review that ARI is a company of
predictable patterns.  This is yet another one.  (Most of them
involve some sort of failure, too . . . if that means anything.)

I guess I'm riding tall, because Keith told me to "get off" my
"damned high horse."  This was after I made a desperate plea
regarding a very serious problem we'd written back and forth about
several times with no resolution. It was the last straw, a last
ditch attempt to let Keith know just how seriously KBBS affected
MLPNet in a negative way, operationally, financially, business-wise.
Keith, apparently, believes KBBS is just a *BIT* flawed and any
sysop who can't make it do what he claims it can do is either: (1)
Inexperienced -- "You should defrag your hard drive more often," he
once said.  "No one is having this problem but you, Jim." (It was a
newly reformatted disk with a fresh installation.) (2) Stupid -- "Is
it MY FAULT you didn't make a backup?" he said TWO WEEKS AGO.  (I
had made TWO backups.) (3) Emotionally distressed -- "It seems you
are using ARI as a scapegoat for all your problems," he wrote. I
responded:  "Fortunately, Keith, most of my problems have NOTHING TO
DO with ARI.  However, ARI is responsible for KBBS related
problems."  I guess ARI now thinks that the inexperienced, stupid,
emotionally distressed sysops of this world are causing the problems
with KBBS, problems they can't duplicate on their end and Hal's not
complaining about them so, therefore . . . they don't exist.  Except
in the minds of those inexperienced and stupid enough to keep
holding out for KBBS v2.0 and the OS/2 version of the same, as ARI
hurdles numerous deadline obstacles and projected release dates with
the ease of a gold medalist (sarcasm).

I won't get into agreements made early on between Keith and myself
regarding promotion of MLPNet and KBBS, my SEQ games, etc.  These
were personal mutual agreements made and ARI defaulted on EVERY
SINGLE ONE, to the best of my knowledge.  These issues were what
planted the seeds of my discontent.  It was only after I saw no
cooperation or follow through on ARI's part that I started paying
closer attention to what was not working over here and why.  I will
note that Keith did follow through with a request I made a month ago
for an immediate SEQ UPLOAD area.  Thanks, Keith.  I guess it's the
little things that count.

One funny little sidebar:  I noticed that ARI's insufficiencies
began when Keith hired all the programming help; you know, the ones
with the cutesy little planet names.  The product and people stopped
performing as they had in the past, problems were tabled, passed on,
put on the infamous "todo" list and lost in the pile, which no
longer exists. Unfortunately, the problems still do.

I no longer expect anything from ARI, not even a working product.
It's what I hope is eventually delivered (since I've already paid
for it in every sense of the word), but KBBS is a classic case of
"too little, far too late."  Still hanging in there for UUCP, Ted?


THANKS AND GRATITUDE
I would like to thank Keith and crew for their efforts to improve
KBBS and bring it up to a competitive and useful level.  Without
them, this review (and my hypertension) might very well have been
impossible.

I hope that the motto I follow at Cherokee Production Studios can be
applied at ARI:

         Don't promise more than you can give.
         Give more than you promised . . .
              and do it when they least expect it.

              (((make it a random act of beauty, perchance???)))

 I do it with my writing and my programming, & that's what I'm doing
here.

ADDENDUM:
Today is July 29, 1995, the release date for this newsletter.  I
released DSNEWS33 this morning, then took my girls to Annapolis to
watch the surf and watch the warships pull in and out of Puget Sound
Naval Shipyard.

When I came home, node three was crashed with an error message, and
node two was locked.  I rebooted the nodes and went to REPAIR/REPACK
the message bases, something I do weekly since I don't use ARI's
internal continuous message packer.  It locked up near the end . . .
yet another corrupted message base. This is perhaps the fourth or
fifth in as many weeks.  I deleted the entire message base (there's
no other way to do it with KBBS when you get this deep and this far)
and rebooted the nodes.  They crashed again with the next call.  I
had to restore from a backup made a week ago, copy in the current
USER*.* files into C:\KBBS, then rebuild everyone's pointers and
status again just to stay on top of things.  It all appears to be
working.  I know I'll be doing this again.

I could reinstall PCBoard and set that up and go thru all the
rigamorole of conversion again.  I've really thought very hard about
this. But KBBS *might* be fantastic software, if and when it is ever
written and more than just a little bit, sporadically functional.
So, what are the options?  Change back, then change again when they
FINALLY deliver what they've been promising?  Or, keep on keeping
on, dealing with errors and corruption, user complaints, having bug
notices ignored by ARI, taking the attitude shovelled out and
shovelling it back, reading Thud Ruder's "Wildcat never crashes"
messages for the rest my life, getting up all hours of the night to
check on the system and reboot it so mail can flow, deleting
corrupted conferences and trees, backing up and restoring from
backups and listening to Keith say "It's not MY FAULT you don't back
up," when, in fact, it's all I ever do anymore with this software.
I'm open to suggestions.


       ۻ   ۻ ۻ  ۻ   ۻ  ۻ ۻ
       ۺ   ۺ ۻ ۻ ۻ ͼ ͼ ۻ
       ۺ   ۺ ɼ ۺ  ۺ ۺ    ۺ    ۻ   ͼ
       ۺ   ۺ ͼ  ۺ  ۺ ۺ    ۺ    ͼ   ۻ
       ɼ ۺ      ɼ ۺ  ۺ    ۺ    ۻ ͼ
        ͼ  ͼ      ͼ  ͼ  ͼ    ͼ    ͼ

Date: 07/30/95 (08:07)                                 80 of 80
From: JIM COLEMAN
  To: KEITH ANDERSON
Subj: HASTA LA VISTA                     Conf: 30: MLP_NET_NEWS
===================================================================

I am setting up PCBoard again, effective immediately.  At least they
have software that works and an OS/2 version. You can't say I wasn't
patient.

Wish I could say "It's been real and it's been fun, my friend," but
I can't.  It's been a nightmare.  Good riddance for both of us.

Please disconnect all my feeds and stuff, effective immediately.




