hugh@slee01.srl.ford.com (Hugh Fader) (03/19/90)
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.
jon@altos86.Altos.COM (Jonathan Ma) (03/20/90)
I've worked with Informix-Turbo for several years. About a year ago, we
tried to do performance tuning on the Altos 2000 (i386 20MHz) system.
We tried so many things to speed up the TPS (transaction-per-second)
using the Informix-Turbo engine without much improvement. As a matter
of fact, for the 2000DP (Dual processor), the spin-wait-lock in shared
memory will slow down the TPS.
In my openion, Informix-Turbo is pretty solid, utilizing the latest
technology in Unix System V IPC, raw disk, and TCP/IP (for networking).
The new version, Informix-Turbo 4.00, is even better with compiled
commit-work and double buffering.
--
-Jon- Jonathan Ma, Altos Computer Systems
Internet: jon@altos.com
UUCP: {uunet,sun,amdahl,apple}!altos!jon
Disclaimer: Those views are mine alone, not my employers'.friedl@mtndew.UUCP (Steve Friedl) (03/20/90)
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...
--
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?" - mebgolden@infmx.UUCP (Bernard Golden) (03/21/90)
: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 : :
sullivan@aqdata.uucp (Michael T. Sullivan) (03/22/90)
:From article <3656@infmx.UUCP>, by bgolden@infmx.UUCP (Bernard Golden): > > 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. Which bugs to fix. WHICH BUGS TO FIX!! ->>>FIX THEM ALL!!!!<<<- Informix is always in the news about how successful they are. One would think that some money could be spent on hiring a programmer or two to fix bugs that have been in the products for years. > 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. Of course, you couldn't actually include a list of known bugs with the product so a customer would know what to look out for instead of spending days trying to find out why a program isn't working, then calling Informix to report the bug only to find out that they already know about it and that the bug won't be fixed until _maybe_ the next realease. > We will cheerfully accept your money for these efforts. Life is too short > for regrets. You have already accepted a customer's money for the product AND for maintenance. What more money do you want (remember: they aren't price increases, they are machine reclassifications)? Somehow, I don't think your posting had the soothing effect that was intended. -- Michael Sullivan uunet!jarthur!aqdata!sullivan aQdata, Inc. sullivan@aqdata.uucp San Dimas, CA +1 714 599 9992
peter@thirdi.UUCP (Peter Rowell) (03/22/90)
In article <3656@infmx.UUCP> bgolden@infmx.UUCP (Bernard Golden) writes: >:In article <376@mtndew.UUCP> friedl@mtndew.UUCP (Steve Friedl) writes: >:>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... >:> >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 [deleted list of reasons why bug fixes are not available] > ... >We are reluctant to continue feeding bugfixes >into ports because of the possibility of unanticipated consequences. This sounds like "we will probably break something else, so it's better to live with the bugs you already know about". >We will cheerfully accept your money for these efforts. Life is too short >for regrets. and this seems to boil down to: "you pay your support money and, in return, we cash the check!" Since this posting lacked the standard disclaimer, one might think that this was a statement on behalf of Informix. If so, it is disturbing in the extreme. I would strongly urge anyone who speaks *officially* for Informix to respond immediately to the net about *exactly* how this person's statements differ from Informix practice. In particular, I would ask for a response to Steve Friedl's statement that known bugs are not fixed in versions for which Informix is still collecting full maintenance. Is this true? Steve, do you have specifics? ---------------------------------------------------------------------- Peter Rowell peter@thirdi.uucp Third Eye Software, Inc. ...!{apple,pyramid,sun}!peter 535 Middlefield ROad, Suite 170 (415) 321-0967 Menlo Park, CA 94025
nigelc@cognos.UUCP (Nigel Campbell) (04/07/90)
In article <1990Mar28.000821.28170@aqdata.uucp> sullivan@aqdata.uucp (Michael T. Sullivan) writes: >:From article <2296@tellab5.tellabs.com>, by segel@tellab5.tellabs.com (Mike Segel): >> >> Could you please tell me of a Software company that actually tells you ALL the >> know bugs in the current release? Would you still buy the package? > >Microport used to do this. Of course, they're out of business. I don't >buy an awful lot of software packages to give an industry-wide rundown. >It sure gave me the warm fuzzies to see that a company cared enough about >its customers to let it know about known bugs and fixed bugs. Would YOU >buy a package from a company with the confidence to supply a bugs list?? >Why wouldn't you? >-- I think that all software vendors are faced with a client base who frequently precieve the vendor as marketing driven and more interested in new sales . Every vendor usually tries to service the client and make information available and obviously not every customer is going to use the service properly or at all which can increase their frustration . Cognos has set various procedures in place which try to ensure that any major problem that a client reports is resolved in a manner that is acceptable to the client . This may be a simple workaround to a patch : patching however raises the clients expectations for the next problem he reports ..... "I want a patch !!!!! NOW !!!!!!" . Information flow between both parties is critical and this requires that the customer designate primary contacts who will liase between the vendor and thehe programmers . This reduces the frequency of bugs reports/newsletters etc being shoved in someone private hoard of notes . The vendors sales force must also be proactive by visiting or calling the clients to see whats happening this may not result in problems being fixed immediatley but creates those warm fuzzies that many people like . Any vendor who does not appear to care about existing clients is greatly reducing the number of reference sites that he can use to leverage new sales . As for would someone buy from a vendor who admits that there are 100,300,500+ outstanding problems with his software I would think that they would if they were given positive feedback from other existing clients who felt that the vendor cared . -- Nigel Campbell Voice: (613) 783-6828 P.O. Box 9707 Cognos Incorporated FAX: (613) 738-0002 3755 Riverside Dr. uucp: nigelc@cognos.uucp || uunet!mitel!sce!cognos!nigelc Ottawa, Ontario CANADA K1G 3Z4