Reasons: Crashes of all supported IDS versions.

Can members of this IIUG forum provide a list of reasons why their supported IDS servers have crashed?.. Is there a list available other than the documented Machine or IDS Release Notes? How much effort was involved in getting the server to run?

Crashes are actually quite rare. IDS just runs. The IIUG server was online for several years until the recent storms near the hosting facility we use caused a power outage and destroyed their primary backup generator (and the backup backup generator ran out of fuel <sigh>. most of my clients have never had any unscheduled downtime, others not for several years. Setting up a new server instance takes only a few minutes initially plus the time to configure the dbspaces that you want and perhaps to move the logs out of the root dbspace. All together less than an hour typically. You can subscribe on the IBM Support site to defect notices. I get one weekly. Most of the defects reported there are for SolidDB, but there are the occasional Informix defect reported. I don't know of a comprehensive listing and anyway, the existence of a bug that brought down someone else's server may never affect your server. Most are dependent on very esoteric conditions. The release notes contain the list of bugs fixed in that release and the list of known bugs not fixed at the time of release. Art Art S. Kagel Advanced DataTools (www.advancedatatools.com) Blog: http://informix-myview.blogspot.com/ Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Advanced DataTools, the IIUG, nor any other organization with which I am associated either explicitly, implicitly, or by inference. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. On Thu, Jul 19, 2012 at 12:06 PM, FRANK J. COMPUTER <frank_in_pr@hotmail.com > wrote: > Can members of this IIUG forum provide a list of reasons why their > supported > IDS servers have crashed?.. > > Is there a list available other than the documented Machine or IDS Release > Notes? > > How much effort was involved in getting the server to run? > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --14dae9340563c2850f04c531357e

As told by Art, crashes are very rare but you can find them... Bugs normally becomes on assertions, but the engine still works. I've found crashes on some IDS instances related to ER or RSS and also related with blobs, but it's very dificult to expose them in a list, because there are no a simple cause-efect. IDS is a very solid and reliable engine, so getting it to crash is very very difficult and it's not easy to know the real cause for it.

On Mon, Jul 23, 2012 at 11:43 AM, VICENTE SALVADOR <vsalvador@deister.es>wrote: > As told by Art, crashes are very rare but you can find them... > > Bugs normally becomes on assertions, but the engine still works. > > I've found crashes on some IDS instances related to ER or RSS and also > related > with blobs, but it's very dificult to expose them in a list, because there > are > no a simple cause-efect. > > IDS is a very solid and reliable engine, so getting it to crash is very > very > difficult and it's not easy to know the real cause for it. > > I wouldn't like to pass the image that it's hard to find the cause for a crash. As I explain why, you may get the impression that I have a lot of experience with them, and that would contradict the point about Informix reliability. Please keep in mind that I work with Informix since 1991 and I'm at Informix/IBM since 1998, with close interaction with technical support although officially I don't work for TS. And typically people don't usually call tech support just to say "hello, everything is running fine" :) In most cases, when we hit an Assert Fail, a quick search in IBM KB for the functions shown in the stack trace can give a very close match for the bug (assuming it's a known bug). Sometimes the functions in the stack trace may not be related to the cause itself (specially with memory corruption issues) and that can make things harder. And eventually we may find a new (never reported) bug. Also, the kind of operation being done can give us very good clues. In my experience I'd say that only once we were not able to find the cause. And when I say "we" I mean myself, the customers and specially the tech support team which must be praised in these situations. But bare in mind that their job cannot lead to a successful conclusion without the help of the customers. I know that some customers complain about their interactions with tech support, and surely some times that may have reasons to do so, but my most frustrating experiences with problem analysis happen when I find a PMR matching my case which was closed due to lack of input from the customer. Believe me, this happens many times. Why? Because for situations that happen only once, usually people have other things to do and can't spend the time investigating what is not seen as a problem anymore. Having said all these, it's obvious that not all problems are equal. I've faced real challenges while looking at bugs (in general and not only assert fails). But it's important to all of us that use the product that we do our best to find the root causes. The bugs shouldn't be there of course, but we all know that all software has them, and usually they don't fix themselves :) Regards -- Fernando Nunes Portugal http://informix-technology.blogspot.com My email works... but I don't check it frequently... --20cf3005dcb2aa532b04c5815be1

All, I have been a huge Informix fan for more tah 15 years, but since upgrading to 11.70 in February, we had more than 20 database crashes, of which 5 separate times, required full recovery of the secondaries. We use to have a combination of HDR, RSS and ER, and eventually got rid of ER. I cannot fault technical support, they have been a pleasure to work with, we have dedicated lab advocates, weekly calls with Jerry, but still, we sort out one issue, then the next happen. All the crashes were Informix related on our primary production cluster, we have a few of them as well. The Connection Managers does help, but working in a 24/7 5 nines environment, i am not too sure about the future of Informix. IDS11.70FC5X5 IBM p795 AIX 7.1 IBM p795 AIX 6.1 So yes, my faith in Informix is slowly dying. Regards, Arnou

This is an example of why I recently asked on the IIUG/IDS Forum, the question "Reasons: Crashes for supported IDS Version", so that we could share our experiences, other than what's on the Machine/Release Notes and Bug Reports. This makes me wonder how long 11.70 was alpha and beta tested, before being released for market distribution.. Are users "pseudo-beta" testing it now? The more complex a piece of software becomes, and IDS certainly is, the more possibility for a failure! All it takes is one little mod to break something complicated. That's why I never rush to upgrade from a stable version to newer versions of anything until it has been beaten-up on for a couple of years!

Very well said, Señor Nuñes!.. I feel its very critical to insulate the server or an instance from crashing, for whatever reason it may be! I'm not familiar with the IDS' architecture, I'd imagine it has a kernel and there are different layers for communicating with it?

On Tue, Jul 24, 2012 at 11:03 PM, FRANK J. COMPUTER <frank_in_pr@hotmail.com > wrote: > This is an example of why I recently asked on the IIUG/IDS Forum, the > question > "Reasons: Crashes for supported IDS Version", so that we could share our > experiences, other than what's on the Machine/Release Notes and Bug > Reports. > > This makes me wonder how long 11.70 was alpha and beta tested, before being > released for market distribution.. Are users "pseudo-beta" testing it now? > I would not say that, and I'm sure that there are many happy 11.7 users (Andrew Ford is a public example - 400+ days of uptime) Also latest Informix major releases benefit from public beta periods. > > The more complex a piece of software becomes, and IDS certainly is, the > more > possibility for a failure! All it takes is one little mod to break > something > complicated. That's why I never rush to upgrade from a stable version to > newer > versions of anything until it has been beaten-up on for a couple of years! > I've written this before, but here I go again... I totally agree with the principle of caution. But that rule of "whatever period" is (pardon me) nonsense. Let me explain why. Over the period of two years you'll see a big number of fixpacks. I'd say we're launching 3 or 4 per year. So 6-8 is a very realistic number... In fact, two years is nearly the major version lifecycle (2007 11.1, 2008 11.50, 2010 11.7, ...). So after two years of a major version, which fixpack will you choose? The latest? That's only around for a few months, and new fixpacks bring new features and not just bug fixes... The truth in my opinion is that there are good and bad fixpacks... I remember particularly 7.31.UD1 and 10.00.FC7... and in any case I still find customer who used (or still use) them for long time... The real question is: All versions have bugs... which ones will you hit? You can be happy with a version for years that caused enormous issues on another customer... And this brings us to the two trouble points: 1- The software should not have bugs (my feeling is that latter versions tend to have bugs mostly on new features). This point if the responsibility of the software maker (and these two points are generic in my view) 2- How will you be able to test the versions on your environment and how much will it cost you? -- Fernando Nunes Portugal http://informix-technology.blogspot.com My email works... but I don't check it frequently... --20cf3074d3e4e03e7404c59c02b8

I'm not the best person to talk about the product architecture... But I could say another controversial thing: Older architectures (like process based systems, not shared threads) can handle failures better... Why? Because if they share less, a corruption or a bug will probably cause less impact on the shared structures. In IDS everything is "shared". And there is a lot of synchronization that needs to take place. If some integrity test fails (I'm thinking more about the memory structures than on the disk structures) what will you do? You could ignore it, hoping it would go away... but usually the engine decides to abort providing data for tech support analysis. On non shared architectures, you can abort just the session... In fact Informix has some parameters that can decided what it does when an assert failure is found. But usually this is only used for debugging. That's why I think that on the kind of architecture used by IDS it's harder to have system stability, and again I praise the development teams for what they achieve. After reading this, you may be wondering, why use this architecture it may be harder to achieve stability? The answer is simply: performance. Regards. P.S.: the ñ are only used in Spanish :) On Tue, Jul 24, 2012 at 11:36 PM, FRANK J. COMPUTER <frank_in_pr@hotmail.com > wrote: > Very well said, Señor Nuñes!.. I feel its very critical to insulate the > server > or an instance from crashing, for whatever reason it may be! I'm not > familiar > with the IDS' architecture, I'd imagine it has a kernel and there are > different layers for communicating with it? > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > -- Fernando Nunes Portugal http://informix-technology.blogspot.com My email works... but I don't check it frequently... --485b393aab73e9503604c59c2122

I agree with Fernando. You are just as likely to hit a bug that no one has ever hit before in an older 'stable' version as in a just released one with the exception of new features of course. That's because if you do find such a bug it will be because you are doing things differently from everyone else using the product. Also note that since IBM took over Informix the regression testing suite has grown enormous! Every bug that has been reported and 'fixed' is added to the regression test suite so that the testers can determine whether an old big has accidentally been reintroduced (a common problem in the pre-IBM days BTW - less so now). Are there new bugs in new versions? Sometimes, most often, as Fernando said, in new features - take the new Readahead algorithms in 11.70 as an example. This wasn't working correctly for every user until 11.70.xC5 - the latest fixpack. On the other hand, 11.50.xC1 was good to go with no performance issues and few critical bugs out of the box (the first six fixpacks however included new features that were more buggy than anything in .xC1). So, while waiting for the first couple of fixpacks is not a bad strategy, why wait several years to be able to take advantage of what 11.70 offers over 11.50 and earlier releases, including: - 10-15% better performance on most queries - New Forest of Trees Indexes - New Multi-Index processing of a single table - Two new DW Join paths - Two new fragmentation schemes that reduce maintenance of high growth rate tables - Storage management improvements - Arrange automatically for chunks to be added to dbspaces when storage gets tight - Configure filesystem based chunks to automatically expand when filled - Online very low overhead table defragmentation I have one client who likes to have the latest and greatest and they are always no more than two fixpacks behind the bleeding edge. They went with 11.50.FC1 and 11.70.FC1 and are now on 11.70.FC4 and thinking about .FC5. They have no regrets. Art Art S. Kagel Advanced DataTools (www.advancedatatools.com) Blog: http://informix-myview.blogspot.com/ Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Advanced DataTools, the IIUG, nor any other organization with which I am associated either explicitly, implicitly, or by inference. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. On Tue, Jul 24, 2012 at 7:49 PM, Fernando Nunes <domusonline@gmail.com>wrote: > On Tue, Jul 24, 2012 at 11:03 PM, FRANK J. COMPUTER < > frank_in_pr@hotmail.com > > wrote: > > > This is an example of why I recently asked on the IIUG/IDS Forum, the > > question > > "Reasons: Crashes for supported IDS Version", so that we could share our > > experiences, other than what's on the Machine/Release Notes and Bug > > Reports. > > > > This makes me wonder how long 11.70 was alpha and beta tested, before > being > > released for market distribution.. Are users "pseudo-beta" testing it > now? > > > > I would not say that, and I'm sure that there are many happy 11.7 users > (Andrew Ford is a public example - 400+ days of uptime) > Also latest Informix major releases benefit from public beta periods. > > > > > The more complex a piece of software becomes, and IDS certainly is, the > > more > > possibility for a failure! All it takes is one little mod to break > > something > > complicated. That's why I never rush to upgrade from a stable version to > > newer > > versions of anything until it has been beaten-up on for a couple of > years! > > > > I've written this before, but here I go again... I totally agree with the > principle of caution. But that rule of "whatever period" is (pardon me) > nonsense. > Let me explain why. Over the period of two years you'll see a big number of > fixpacks. I'd say we're launching 3 or 4 per year. So 6-8 is a very > realistic number... > In fact, two years is nearly the major version lifecycle (2007 11.1, 2008 > 11.50, 2010 11.7, ...). So after two years of a major version, which > fixpack will you choose? The latest? That's only around for a few months, > and new fixpacks bring new features and not just bug fixes... > > The truth in my opinion is that there are good and bad fixpacks... I > remember particularly 7.31.UD1 and 10.00.FC7... and in any case I still > find customer who used (or still use) them for long time... The real > question is: All versions have bugs... which ones will you hit? You can be > happy with a version for years that caused enormous issues on another > customer... And this brings us to the two trouble points: > 1- The software should not have bugs (my feeling is that latter versions > tend to have bugs mostly on new features). This point if the responsibility > of the software maker (and these two points are generic in my view) > 2- How will you be able to test the versions on your environment and how > much will it cost you? > > -- > Fernando Nunes > Portugal > > http://informix-technology.blogspot.com > My email works... but I don't check it frequently... > > --20cf3074d3e4e03e7404c59c02b8 > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --f46d042ef65f267daa04c59c6ac2

The bottom line is: If something is stable and has been working with no problems, why change it?.. Especially for mission critical applications! Unless a new requirement which the current version cannot provide and a newer version does provide, then the newer version will be evaluated. Even so, they will exhaust all possible remedies before deciding on upgrading. Do you see any big enterprises upgrading versions often?.. NO! Many of them are still running on older version until they're no longer supported. Based on past experiences, the majority of businesses have grown skeptical about upgrading to newer version, unless they've seen consistent stability, and even then, they play it safe! Sure, we will test it, but when a business with thousand of users depend on their systems, unscheduled downtime can cost millions, and even the future of that business!

So, perhaps the logic behind the management of multiple shared threads needs to be revisited to handle exceptions, as well as anything that could generate assertions? Mission Critical applications cannot afford to suffer unscheduled downtime, that could cost millions and even the future of a business! Sorry about the "ñ", I've seen "nh" used in Portuguese, but not followed by an "e" :)

Frank, that's just not what we are seeing. We have three current clients upgrading, all are mission critical applications running on Informix versions from 7.31UC2 to 9.40, 10.00 and 11.50 (yes that's four versions, one client is upgrading many 9.40 and 10.00 servers to 11.70) and I get requests to help with upgrades or to purchase upgrade licenses all the time. These are not small potatoes mom-and-pop companies. A major insurance company, a major food retailer, a state court system, etc. Art Art S. Kagel Advanced DataTools (www.advancedatatools.com) Blog: http://informix-myview.blogspot.com/ Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Advanced DataTools, the IIUG, nor any other organization with which I am associated either explicitly, implicitly, or by inference. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. On Tue, Jul 24, 2012 at 8:56 PM, FRANK J. COMPUTER <frank_in_pr@hotmail.com>wrote: > The bottom line is: If something is stable and has been working with no > problems, why change it?.. Especially for mission critical applications! > > Unless a new requirement which the current version cannot provide and a > newer > version does provide, then the newer version will be evaluated. Even so, > they > will exhaust all possible remedies before deciding on upgrading. > > Do you see any big enterprises upgrading versions often?.. NO! Many of them > are still running on older version until they're no longer supported. > > Based on past experiences, the majority of businesses have grown skeptical > about upgrading to newer version, unless they've seen consistent stability, > and even then, they play it safe! Sure, we will test it, but when a > business > with thousand of users depend on their systems, unscheduled downtime can > cost > millions, and even the future of that business! > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --e89a8ffbae69a8eaa404c59d4ebd

On Wed, Jul 25, 2012 at 1:56 AM, FRANK J. COMPUTER <frank_in_pr@hotmail.com>wrote: > The bottom line is: If something is stable and has been working with no > problems, why change it?.. Especially for mission critical applications! > That's a biased way of putting the question.... It ignores some facts: 1-Being stable today does not mean it will be stable tomorrow. I distinctly recall a night in 2003 when I hit a new bug... Happened in all supported versions of Informix. The environment was stable for a long time. We did upgrade and if I recall correctly an alert was published... I'm sure most people didn't upgrade. And many were at risk of hitting a known (from that time) bug. 2- Stable usually means you do things as the product supported at the time it was published... many times this means you're wasting a lot of new features 3- In terms of operating systems and databases it also means you tend to be stuck on a corner, and suddenly someone wakes up and is on a non-supported system. That the typical process is rushing to a badly planned upgrade (under stress) that could have been properly planned Do you see any big enterprises upgrading versions often?.. NO! Many of them > are still running on older version until they're no longer supported. > Depends on what is a big company (specially in a small country). I can think of a customer who was stuck on v7 for too long. That finally moved to v10 and started to explore some new stuff. They an hardware upgrade forced another database upgrade to 11.50.FC3. They have been upgrading very successfully until 11.50.FC7.... Now they're getting stuck again, "avoiding" 11.7 due to what I'd consider mostly political reasons. How have they moved along the 11.50 fixpacks successfully? Very simple... They have production, QA, Test and Dev environments. Typically QA and production are always on same version. New releases were rapidly introduced in dev, and if they worked we moved it to Test and so on. Many issues were early detected in DEV leading to configuration adjustments or simply to decision to avoid some patch level. I believe that's the way to do it. > > Based on past experiences, the majority of businesses have grown skeptical > about upgrading to newer version, unless they've seen consistent stability, > and even then, they play it safe! Sure, we will test it, but when a > business > with thousand of users depend on their systems, unscheduled downtime can > cost > millions, and even the future of that business! > This is also a reason to upgrade... How many customer do you know that effectively check the new versions fixes, the alerts and do some kind of risk analysin on the documented bugs for their environment? I'd say 0... And that's not a good policy.... (oh yes, today I'm particularly politically incorrect). Again, to be clear, I believe software suppliers should commit to reduce the number of bugs in their software... I have a customer that has a funny expression when he sees a new software bug.... "that's the usual... if this was a plane we'd all be dead by now"... We call it software engineering, but I do believe bridges, planes nuclear plants etc are really a different kind of "engineering" :) Regards > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > -- Fernando Nunes Portugal http://informix-technology.blogspot.com My email works... but I don't check it frequently... --00235429cdec70670604c59d6141

On Wed, Jul 25, 2012 at 2:12 AM, FRANK J. COMPUTER <frank_in_pr@hotmail.com>wrote: > So, perhaps the logic behind the management of multiple shared threads > needs > to be revisited to handle exceptions, as well as anything that could > generate > assertions? > I don't think you can do much better besides improving the test phase. The thread that sees some inconsistency may not (and many times it's not) the thread that caused it. Again, this is very typical with memory corruptions. So what can you do? Close the system and recover which in many systems is very quickly. And even non shared architectures have shared structures. So they don't avoid the problem completely while at the same time they suffer from performance. > Mission Critical applications cannot afford to suffer unscheduled downtime, > that could cost millions and even the future of a business! > True, but frequently an overrated truth in the real world.... Reminds me of the customers that invest heavily on clustered systems which many times cause more downtime than the ones they try to prevent. In one of the customers I was thinking in another note, although they don't want to stop Informix, they'll happily stop the machines where it runs to install regular released patches for the OS that solve issues they never faced... Weird, hmmmm? Politics. > Sorry about the "ñ", I've seen "nh" used in Portuguese, but not followed > by an > "e" :) > We can use nh and lh followed by some vowels (nha, nho, lha, lhe,lho). But in my name it's just an "n" (nes)... But that's really not important :) > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > -- Fernando Nunes Portugal http://informix-technology.blogspot.com My email works... but I don't check it frequently... --20cf3005dcb245192a04c59d9082

I still believe in "If everything has been stable and fulfilling the needs, don't change it until the support life cycle has ended!". Changes are expensive and as software becomes more complex, more probabilities for something to go wrong! If you were to conduct a survey of the top Fortune 500 Corporations, you'll find out that most of them are still running stuff that's at least 3 to 30 years old! Some monsters, like the Social Security Administration have 85% of their code still runing in COBOL with DL/I calls to IMS. Even a change request to alter a table needs to be carefully evaluated and may not even be approved!

I agree with you. ________________________________ From: FRANK J. COMPUTER <frank_in_pr@hotmail.com> To: ids@iiug.org Sent: Wednesday, 25 July 2012 11:50 AM Subject: Re: Reasons: Crashes of all supported IDS versions [27820] I still believe in "If everything has been stable and fulfilling the needs, don't change it until the support life cycle has ended!". Changes are expensive and as software becomes more complex, more probabilities for something to go wrong! If you were to conduct a survey of the top Fortune 500 Corporations, you'll find out that most of them are still running stuff that's at least 3 to 30 years old! Some monsters, like the Social Security Administration have 85% of their code still runing in COBOL with DL/I calls to IMS. Even a change request to alter a table needs to be carefully evaluated and may not even be approved! ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum.

Say you are running a version of Informix 3 years old and a new version appears Option A) Upgrade immediately - high risk Option B) Wait for 1- 2 years until other customers feel it is stable and upgrade, in the process find 1) There are new reserved words in the sql language and your app/schema needs 5 changes 2) There are features removed and your app needs change in 3 places 3) Some bugs need fixing. Option C) Wait for 10 years 1) There are new reserved words in the sql language and your app/schema needs 100 changes, you spent ANOTHER 7 YEARS adding usage of the new reserved words to your app/schema! 2) There are features removed and your app needs change in 100 places, you spent ANOTHER 7 YEARS adding usage of the removed feature to your app which will need to be remediated. 3) Some of your source code has been lost and that part has to be rewritten from scratch and peoples memorys of how it should work. Spent next 2 years rewriting that part of the code as different customers say it used to work differently then the rewritten version. Option D) Wait for 15 years In the 14th year the last hardware dies which runs an OS version compatibile with that version of Informix you were running. You know that 6 months upgrade/test process - well you are down and need to do that before you can get running again - screwed! You will need to upgrade eventually when hardware moves on and no OS you can run on the new hardware is compatibile with your database or app. My policy is: 1. Play with the FC1release and use for compilation testing/sniff testing , you have plenty of time to make any codes changes to ensure your code will compile/run against that release without majro issues. Any bugs you find the vendor has plenty of time to fix. Even better would be to get on the beta program and complain loudly if they remove a feature you need. Complaining 5/10 years later is not going to help! Also the vendor knows their customers rely on that feature so it needs it's fair share of testing even if the developers want to remove the feature. 2. Play again with a later release - used to be FC4 but with the QA seeming to have gone down I am holding off on even 11.70.FC5 for now. 3. When people on these lists say a release is stable and stop mentioning new bugs, get it, retest and consider using it for real. There is always a cost whether you upgrade or not.. David. On 25 July 2012 at 02:50 "FRANK J. COMPUTER" <frank_in_pr@hotmail.com> wrote:> I still believe in "If everything has been stable and fulfilling the needs, > don't change it until the support life cycle has ended!". Changes are > expensive and as software becomes more complex, more probabilities for > something to go wrong! > > If you were to conduct a survey of the top Fortune 500 Corporations, you'll > find out that most of them are still running stuff that's at least 3 to 30 > years old! Some monsters, like the Social Security Administration have 85% of > their code still runing in COBOL with DL/I calls to IMS. Even a change request > to alter a table needs to be carefully evaluated and may not even be approved! > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. >

One question I would have is are all your known issue fixed in the latest 11.70 X patch or are you waiting for fixes? If all fixed how long have you been running the fixed version? On 25 July 2012 at 01:56 "FRANK J. COMPUTER" <frank_in_pr@hotmail.com> wrote:> The bottom line is: If something is stable and has been working with no > problems, why change it?.. Especially for mission critical applications! > > Unless a new requirement which the current version cannot provide and a newer > version does provide, then the newer version will be evaluated. Even so, they > will exhaust all possible remedies before deciding on upgrading. > > Do you see any big enterprises upgrading versions often?.. NO! Many of them > are still running on older version until they're no longer supported. > > Based on past experiences, the majority of businesses have grown skeptical > about upgrading to newer version, unless they've seen consistent stability, > and even then, they play it safe! Sure, we will test it, but when a business > with thousand of users depend on their systems, unscheduled downtime can cost > millions, and even the future of that business! > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. >

Dave, that's a very realistic explanation!.. As to IBM's acquisition of Informix, my theory is: They did it with the intention of persuading Informix users to migrate to DB2, Rational, Websphere, etc. and eventually phase out Informix. This is what Microsoft did when they acquired Visual Fox Pro, migrate users to Office Access, freeze VFP, end support and phase it out! They also did this with Sybase to SQL Server. However, reality is: Informix users have been resistant to convert, therefore this product line has not been generating profits for IBM so now they're using tactics to get users to upgrade to latest versions, which IMHO have not been thoroughly QA'd. If this strategy is not successful, eventually you're going to see IBM freezing any new releases of Informix, and the rest you can figure it out.. It would be interesting to know from Informix users: What contingency plan do you have in the event that IBM were to phase out Informix?.. What alternate DBMS would you migrate to?

On Sun, Jul 29, 2012 at 12:53 AM, FRANK J. COMPUTER <frank_in_pr@hotmail.com > wrote: > Dave, that's a very realistic explanation!.. > > As to IBM's acquisition of Informix, my theory is: > I do like the word "theory"... > However, reality is: Informix users have been resistant to convert, > therefore > this product line has not been generating profits for IBM so now they're > using > tactics to get users to upgrade to latest versions, which IMHO have not > been > thoroughly QA'd. If this strategy is not successful, eventually you're > going > to see IBM freezing any new releases of Informix, and the rest you can > figure > it out.. > Version 9.4, 10, 11, 11.5, 11.7 were releases made by IBM (9.4 was not developed under IBM). 10 years have passed. You can still have some sort of support for several "unsupported" versions, without paying more. You can get support paying extra for unsupported versions. These two points were clarified in the group recently. Version 11.50 has been great. I haven't seen problems in v11.7 except for new features. I'd say your theory needs a reality check... I can't speak for the future, but let's at least get the record straight when we mention the past... Informix?.. What alternate DBMS would you migrate to? > That was already answered. Check with many SAP customers... -- Fernando Nunes Portugal http://informix-technology.blogspot.com My email works... but I don't check it frequently... --20cf30363ebbc784e404c6012f95

Hi IBM continues to be committed to Informix with an expectation that the product will continue to meet the expectations of the market. We have had an aggressive growth strategy in place for several years and continue to deliver significant innovation to the market. We have seen significant adoption of both versions 11.5 and now 11.7 and will soon be starting our EVP for vNext. Our quality expectations are high. I would be happy to meet and discuss any issues that any of your are facing in your deployments. I would also be happy to meet with the leadership @ your companies to discuss IBM vision for Informix. Regards, Jerry Jerry Keesee World Wide Director, Informix Software IBM Data Management Tel:(913)599-8713 Cell:(913)710-7472 From: "Fernando Nunes" <domusonline@gmail.com> To: ids@iiug.org, Date: 07/29/2012 07:32 PM Subject: Re: Reasons: Crashes of all supported IDS versions [27861] Sent by: ids-bounces@iiug.org On Sun, Jul 29, 2012 at 12:53 AM, FRANK J. COMPUTER <frank_in_pr@hotmail.com > wrote: > Dave, that's a very realistic explanation!.. > > As to IBM's acquisition of Informix, my theory is: > I do like the word "theory"... > However, reality is: Informix users have been resistant to convert, > therefore > this product line has not been generating profits for IBM so now they're > using > tactics to get users to upgrade to latest versions, which IMHO have not > been > thoroughly QA'd. If this strategy is not successful, eventually you're > going > to see IBM freezing any new releases of Informix, and the rest you can > figure > it out.. > Version 9.4, 10, 11, 11.5, 11.7 were releases made by IBM (9.4 was not developed under IBM). 10 years have passed. You can still have some sort of support for several "unsupported" versions, without paying more. You can get support paying extra for unsupported versions. These two points were clarified in the group recently. Version 11.50 has been great. I haven't seen problems in v11.7 except for new features. I'd say your theory needs a reality check... I can't speak for the future, but let's at least get the record straight when we mention the past... Informix?.. What alternate DBMS would you migrate to? > That was already answered. Check with many SAP customers... -- Fernando Nunes Portugal http://informix-technology.blogspot.com My email works... but I don't check it frequently... --20cf30363ebbc784e404c6012f95 ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum.