A call to arms!
Posted in 1993
We're in the middle of negotiating with Informix to provide an adequate work-around for error -4518. Mainly, we have a fairly complex chunk of code, reports which need wordwrap, clipped, print using, and so on-- basically finding about every way one can trip -4518 ("out of temporary string space"). The workarounds are (a) not satisfactory (we *need* the formatting) and (b) not sufficient -- even with *all* the workarounds in place, we still get it. My point in posting this is NOT to start a "how to work around -4518 error" thread again, nor do I want more ideas how to work around it (I feel I'm thoroughly expert at it now, up the point where the local Informix guru said I knew more about it than he did, and that we'd been more than patient with this bug and the workarounds). So, we've asked Informix to supply us with one of four things: - A patched version of the runner and runner-making tools that has this bug *fixed*; or - A patched version of the runner and runner-making tools that has a simple way for us to set the number of elalloc blocks to whatever we want (20...100...1000, whatever it takes so we can demo/debug our app until the next release is out, which they hint is very late this year, which is too late for us); or - A copy of RDS 5.0, if it's fairly stable; or - Source code for RDS & family + non-disclosure agreements + agreements we won't ask for tech support for RDS bugs. To my mind, any of the four are technically possible. Informix, so far, has taken a very dim view of helping. I find this highly irresponsible. My reason for posting is: If you're also fed up with Informix's policy of not providing patches or other adequate solutions to problems (and "don't use that feature" isn't an "adequate workaround"!), now is a good time to let your marketing folks know you're fed up and won't accept that attitude any longer. We've started stirring up the pot, but we could really use some help stirring. This isn't about -4518 errors, it's about Informix's attitude regarding support. They seem so intent on providing new features, and obtaining new clients, that they are skimping on supporting existing products and clients. If this is truly the corporate attitude, then all Informix customers are in trouble, and this makes me have doubts about Informix's long term stability, which should bother every reader of this group. And the broken record of "it's too hard to supply patches for all the different products and architectures" is pretty lame. I would point to vendors like Sun who supply copious patches (and they have multiple architectures to support and multiple releases). Especially with something that ought to be fairly architecture independent like RDS (just recompile, I should hope). (Nor do I want to hear anything about the thorough release engineering -- my discovery that nobody tested esql/c 5.0 with rds 4.1 (they don't mix if you try to make a customer runner using esql 5.0 .ec files) shoots big holes in any claims of rigorous release testing!) Our lone cry in the wilderness, and the $100K they stand to lose from us if this isn't resolved, apparently isn't enough to make them listen. (Even though this ought to pay for a whole programmer or two for a year!) However, it is an opportune moment for anyone else who feels likewise to start applying pressure along with us. With sufficient pressure they might actually change. I seem to recall a similar fiasco with HP support, with a positive outcome, so I don't think we face an impossible task. But everyone at Informix keeps saying it has to go through marketing, so if you're with us, start ringing those phones. Get tough, don't accept sloppy workarounds and excuses. -- Andrew Burt aburt@du.edu "But if he was dying he wouldn't bother to carve "Aaaaargh", he'd just say it."