Informix fix policies (LONG) (Was Re: Informix support: Where are you?)

Any opinions expressed here are mine alone; they do not reflect Informix policy, management, stockholders, pets of same, ... you get the idea. All statements reflect my personal knowledge and understanding; nothing more. In article <Apr.29.13.43.02.1992.28725@pepper.rutgers.edu> bohannon@pepper.rutgers.edu (Philip Bohannon) writes: > >4-6 years ago, I had ongoing interaction with Informix Tech support >over a number of issues. For example, they were dropping support for >their pre-SQL product and not offering any backward compatibility or >upgrade path to SQL because it was a "different product". I came away Whoa. "No upgrade path" to the SQL products is incorrect. If you are claiming that Informix 3.3 owners at the time the SQL products came out (originally just ESQL/C, I-SQL, and C-ISAM 2.11+) had no upgrade offers, I'm almost certain you're wrong. Perhaps the upgrade specials had expired by the time you got around to upgrading; that's a separate issue. Anyway, ... >with the following analysis, essentially in agreement with Chad: > >o There are some smart developers at Informix. They really do have a > nice product. Thank you. >o Tech support *never* sends out bug fixes, making them almost > totally useless to a serious developer. This is not their Folks, this is BULLSHIT. This popular myth, as put forth by Mr. Hogg et al, is just NOT TRUE. It's not even REMOTELY true nowadays. I'll grant you at the outset that in the 4-6 years ago time window, bugfix releases were relatively rare and encompassed only the most serious bugs (typically those in SE, C-ISAM, and Turbo). This does NOT reflect current practice. For any given major release, there has been a series of follow-on bugfix releases. For example (ISQL/ESQL versions used below; add 1 for C-ISAM and subtract 1 for Turbo and 4GL. UNIX versions used for demonstration): 2.00.00 begat 2.00.01, .02, .03, .05 2.10.00 begat 2.10.00, .00B, .00C, .00D, ... 2.10.03 begat 2.10.03, .03B, .03C, .03D, ... .03L, .03L1, .03M, ... In those days, like I said, bugfix versions tended to include a few (TOO few), highly-critical fixes. Starting with 4.00, a new numbering scheme emerged. All products were reversioned to the same parent version (e.g. 4GL went from 1.10.03 to 4.00). 4.00.UC1 first commercial release port-level bugfix versions UC2, UC3... 4.00.UD1 bugfix level 1 port-level bugfix versions UD2, UD3... (to UD7 at least) 4.00.UE1 bugfix level 2 port-level bugfix versions UE2, UE3... 4.00.UF1 bugfix level 3 port-level bugfix versions UF2, UF3... 4.00.UG1 bugfix level 4 (November 1990) port-level bugfix versions UG2, UG3... 4.00.UH1 bugfix level 5 (January 1991) port-level bugfix versions UH2, UH3... 4.00.UJ1 bugfix level 6 port-level bugfix versions UJ2, UJ3... 4.00.UK1 current bugfix level For example, Mr. Hogg's lament about the core-dump-in-last-field-of-a-CONSTRUCT (bug 7628/7650) was fixed in the UG1 update (and may have been rolled into some UE or UF ports. The problem with that one was that it didn't occur on all platforms, so it was originally mislabeled as machine-specific). Anyway, these went out well over a year ago, assuming a reasonably popular platform. Each of these version levels represents a set of bug fixes. Since most of these complaints haven't referenced specific bugs, I can't give specific dates. 4.10 engines/embeddeds have had the following update versions: 4.10.UC1 first commercial release port-level bugfix versions UC2, UC3... 4.10.UD1 bugfix level 1 port-level bugfix versions UD2, UD3... 4.10.UE1 bugfix level 2 port-level bugfix versions UE2, UE3... 4.10.UF1 bugfix level 3 port-level bugfix versions UF2, UF3... 4.10.UG1 current bugfix level A "maintenance release" called 4.11 will be coming at some point in the future, which will encompass all above fixes plus others TBD. 4.10 tools (ISQL, 4GLs) have had the following update versions: 4.10.UC1 first commercial release port-level bugfix versions UC2, UC3... 4.10.UD1 bugfix level 1 port-level bugfix versions UD2, UD3... 4.10.UE1 current bugfix level (this is almost frozen now.) A "maintenance release" called 4.11 will also be coming at some point in the future, which will encompass all above fixes plus others TBD. For example: On Sun, the 4.10.UC2 tools maintenance port added the fix for bug 11743; the UC3 port added fixes for 11364 and 11768. (Those latter two bugs have been fixed on a whole bunch of platforms, as they are rather nasty regressions). The AT&T 3B2 4.10.UD2 tools release includes about 20 bugfixes since UD1 (and this code set will probably become a general UE1 release). etc. > choice. After wading through the front ranks, you can > find some in tech support who understand the bug you are > running into. Unfortunately, they are prevented from helping > by company policy. (other than giving workarounds. Whoopee.) More bullshit (and this "prevented from helping by company policy" is *pure* fiction), as indicated above. >o The origin of this thread, a nasty bug in the current C-ISAM and > Informix's refusal to provide a fix, shows that this policy > is still firmly in effect. Care to give a specific bug # ? Has this claim actually been acknowledged as being a bug in the first place? >Informix's maintenance and support *policies* seem designed to milk >the maximum money out of developers and customers with the minimum >possible investment in customer support. Thus, in the fashion of (at Maybe to you. To me, the policies seem designed to make the price of services more reflect the actual cost to provide them, rather than shifting the cost burden to new customers. >least the old) IBM, the customer is motivated to pay for maintenance >by the cost of changing development environments, rather than any >benefit of tech support. In your opinion. Are Informix's policies (e.g. that updates require maintenance agreements) really that out of line with the competition? >If any of these decision-makers had to *use* their products, that >policy would change fast, because it is *VERY FRUSTRATING*, and left >me with an abiding distaste for the company (and an abiding sympathy >for the tech support people who really wanted to help). > >Probably the best thing an Informix employee reading this thread could >do is digest it and slide a copy under company officer's doors (late one >night). Did it occur to you that upper management might give such comments more weight if they came direct from the field rather than from within? >Philip Bohannon (bohannon@paul.rutgers.edu)