Tech support

I have a case for the debate about tech support / Informix in general. This was written a few months ago. I believe that every time I have called Informix support in the last year (except just now), I have spent 15 minutes or more on hold. The last time I asked a question, it was, "is the transaction log file [SE] written synchronously," which is of vital significance to us since if the answer is "no," we do not have dbase integrity in the event of a crash. I just talked to an engineer who read the case info to me: <case record> case # 126809 isql 2.10.03B opened: 4/10/91 closed: 9/18/91 by administrative default, i.e. it fell on the floor Wants to know if sync triggers code for transaction buffer write. Later: Wants specific proof of correctness of log writing. I was eventually referred to someone for authorization to receive the information on Informix internals. <end what I jotted of case record> Note that the 1st person I spoke to never understood the question, and the secrecy involved in disclosing whether their program is reliable (amounting to whether they open a file O_SYNC or not) is ludicrous. I am not sure that the person who read the case to me understood it either, although eventually he said he did and stopped repeating how a rollforward is done. I believe I tried a little further, but forget what happened exactly except that I never got an answer. Meanwhile, we found out from the kernel side that the transaction log wasn't written synchronously, and I also heard indirectly that Informix's response to that was that the transaction log was for transactions and not for dbase integrity across a crash, i.e. if you wanted transactions, you sacrificed dbase integrity. Our solution was to modify the kernel so that synchronous writing was forced somehow. The one time we got support that I was impressed by was right before the case I just discussed, when we had the big transaction rollforward nightmare; that was case #125978. They did go to extra lengths then; my only complaint there is that I believe the extra long time it took (~24 hours on a dedicated mainframe) probably results from a bad rollforward algorithm and I don't think they seemed interested in investigating it. In the latter case we had to modify the binary to make it use extended addressing in order to rollforward a single transaction; we monitored the progress through the file via the kernel and found that performance decayed exponentially, my guess is because of traversal of a growing linked list for each element of the transaction. The result of our experiences with Tech support was as Hogg has described: all 4 of us who had to call (3 programmers and a production person) dreaded the experience. After concluding in negotiations that Informix was not committed to making their product reliable (our database cannot be corrupted) we are replacing Informix in our project. Somehow in our dealings with other vendors, we had built the expectation of more support than Informix was willing to give. On the other hand, I have been impressed with the recent participation in the board/list by Informix employees, since it gives me the impression that there are responsible people there who understand the products' internals and care about the products and the customers. Now if the business policies would omit flat out refusal to make things work under a "support" agreement.. Bill Ross Computer Sciences Corporation NASA Ames Research Center