Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!wuarchive!rex!ames!amdahl!nsc!pyramid!infmx!bgolden
From: bgolden@infmx.UUCP (Bernard Golden)
Newsgroups: comp.databases
Subject: Re: Problems With Informix Turbo Engine
Message-ID: <3656@infmx.UUCP>
Date: 20 Mar 90 17:51:58 GMT
References: <40651@fmsrl7.UUCP> <376@mtndew.UUCP>
Reply-To: bgolden@infmx.UUCP (Bernard Golden)
Organization: Informix, Menlo Park, Ca. U.S.A.
Lines: 63

:In article <376@mtndew.UUCP> friedl@mtndew.UUCP (Steve Friedl) writes:
:>In article <40651@fmsrl7.UUCP>, hugh@slee01.srl.ford.com (Hugh Fader) writes:
:>< I've seen several postings which say some very bad things about the
:>< shared memory scheme used by the Informix Turbo Engine. However, I have
:>< seen no postings to the contrary from people at Informix. This is of
:>< particular interest to me since I have just completed an evaluation of
:>< Informix (4GL, SQL, Turbo) and I thought they were pretty good
:>< products.
:>< 
:>< How about some responses from you folks at Informix. I know some of you
:>< read this newsgroup.
:>
:>There are a whole host of questions you might want to ask them.
:>You might ask whether they can do anything about shared memory
:>lockups.  You might ask them whether they care.  You might ask
:>whether they ever send "regrets" that bug fixes will not be made
:>available for some machines for which they still accept full
:>maintenance money for.  Gee, so many questions...
:>

Yes, we can do something about shared memory lockups.  The primary effort 
we have made is to significantly upgrade the robustness of this area of
the code in our next release (4.00, available momentarily).  While not
trying to excuse any problems you may have encountered in the past, this
is an extraordinarily complex area of the product, which makes sense,
given that it controls concurrency, disk updating, and logging.  It is
also an area of the code that impacts overall performance of the product,
so we have to try to think up clever ways of doing this work; a brute-force,
absolutely safe approach is usually not acceptable.

We care a lot.  I believe the quality of our product is very good and we
are constantly striving to further improve it.

With respect to the issue of bug fixes, I don't know which particular bug
fix you are referring to.  There are tradeoffs that come into
play when deciding which bugs to fix, with the issues usually being
severity of a particular bug, severity of other bugs outstanding,
desireability of a feature vs. some number of bugs that could be coded in
the same time, etc.  Our policy is that the most severe bugs get priority.
Sometimes this means that a less-severe bug will not be addressed in
the next release.  This of course ignores the issue of the bug that flows
in the day after you freeze a release.  For example, release XXX freezes
3/15.  On 3/16 an irritating but not devastating bug comes in from a
customer.  Release XXX won't be held up for this fix, so it is sent off
to be ported to lots of machines.  This process takes months to complete
on every machine we support.  Customer YYY (who reported the bug )
gets release XXX on his machine five months later and sees the bug and
wonders why it isn't fixed.  We are reluctant to continue feeding bugfixes
into ports because of the possibility of unanticipated consequences.

We will cheerfully accept your money for these efforts.  Life is too short
for regrets.

-b


:>-- 
:>Stephen J. Friedl, KA8CMY / Software Consultant / Tustin, CA / 3B2-kind-of-guy
:>+1 714 544 6561 voice   /   friedl@vsi.com   /   {uunet,attmail}!mtndew!friedl
:>
:>"How could anybody look at Miss April and *not* believe in a God?" - me
:
: