Re: Informix Tech Support?

>> >My company has basically given up on getting any support from Informix. > >> This is a discussion thread I have wanted to see for quite some time. > >> My company has been using Informix since 1990, for the most part the >[SNIP] >> I have _NEVER_ received _ANY_ exceptional assistance from Informix >> Tech Support in the 8 years I've used them, and on a scale of 1 to 10 >> I would say they average about 2. That scale, by the way, has WRQ >> at about a 9 and CheckFree at a 5, just for comparison. > >> I currently am waiting for an answer as to why I always get the >> message "unknown error message 874" every time I try to set >> pdqpriority. Error message text points at the optimizer, and >> says to note conditions and call tech support. Fine. Conditions >> are no one else is logged onto the damn host, I'm the only user, >> I'm sitting in the ISQL window, no jobs/queries are running, and >> I type set pdqpriority high. Or 100. Or low. Or whatever. Same >> error message. Tech support asks me to fax them my onconfig, a >> printout of onstat -a (which is huge), mayby try running oncheck >> against each table and index (!!!) as "it might help", etc. >> >> Look, I don't expect people to have an instant answer to a problem >> when I call, but I do expect to talk to someone who has a clue. For >> what I pay every year (and if I could convince the board that we >> shouldn't be paying we wouldn't be, but they keep hearing that you >> have to budget 15% for "software support", so we keep on spending...) > >> Anybody have better luck than we have? > >Yes I do. Being a Regency Support customer may help some but mostly it >has to do with knowing how the game is played. If you do not get >immediate help ask the tech to escalate the case to priority level 2 >(default is level 3). Support priority level 2 means that a manager >begins tracking case progress and the tech is encouraged to pass the >case to another higher level tech. If the case is business critical >you could have it marked priority level 1 (which needs to be negotiated >with the tech and/or his/her manager because:) here the tech on the >case can't go home until your problem is at least alleviated. Just a couple of comments, as a member of advanced support. P1 should only be used with a truly downed system. It really should not be used for those situations where you're simply trying to apply pressure to get the problem resolved faster. The people who do the P1s have a main focus of simply getting the system back up. If you have a re-occuring problem, maybe a SEGV, or SQL error that doesn't make sense, you're far better off to try to leave it as a P2 because the engineer will focus of the cause of the problem. If you are disassitified with response, then the best thing to do is to call the 800 number and request to speak with a manager about the case. There are three internal codes which are used to indicate levels of seriousness and degree of management involvement. If you are unhappy with the progress being made, you can always request that the case be given to someone else, again by calling the 800 number, or by contacting your sales force. It's true, a P1 requires round the clock attention. Both on the engineer's time and the customer's. If the engineer needs to talk with the customer to get certain things done on the customer's machine, then the customer must also be available. There are several things that can be done to help the engineer resolve the problem. 1) have some form of dial-in modem and/or internet access available. When you're down is not the time to by a modem. 2) Use email, not faxes. If you send your onstats, af.xxx files via email, they will get into the case notes. That way any informix engineer has access to that data. 3) Try to describe the symptoms, not what you think is the solution. Going into possible solutions before giving the engineer time to analyze the problem will only confuse the issue. 4) Expect some form of contact at least every two days. There are several levels of engineers within the support organization. The front-line engineers are the ones that will take the initial call. Their primary job is to gather information about the problem. If this is a commonally known problem, then they will offer a solution. Above them are "team-leaders" who will have more specific knowledge about components of the product, but will not necessarily be coders. Then you get into the advanced support organization. This tends to be divided into two broad groups. The first group will focus on problem isolation, while the second group will focus on bug "quick fixes" and suggested patches for R&D to approve. Each group needs the information that has been gathered by the previous group. If the case gets esclated too fast, then the information will not have been gathered and the whole process will suffer. Also, the advanced support groups generally think in terms of somthing really being wrong with the product while the front line engineers generally think that somthing might be wrong with the configuration or set-up. For instance, I've had cases passed to me that were esclated way too fast. Since I normally work at the debug level, I automatically assume that a real bug has been passed to me. I had one case passed to me involving a "running out of memory" situation. I automatically assumed the worst - massive memory leaks, some type of kernel problem causing shmat() to fail, etc. I had all kinds of stack traces, diagnostic code put into the engine, dbx breakpoints, truss outputs, etc trying to figure out what was wrong. Finally I noticed that PDQ was turned on, but no DSS memory was set. This took me two days to spot. I'm fairly confidant that a front-line engineer would have spotted this right away. However, the customer felt that the front-line engineer was incompetent and pushed for esclation. I really feel in this case that the problem would have been resolved quicker by the front-line engineer, simply because of the different type of work that the front-line does from the back-end. I guess what I'm really saying is try to work with the front-line person. If he is asking for onstats and/or af.xxx files, try to get them to him (electronically) as quickly as possible. However, if you feel that no progress is being made, request contact with a manager to transfer the case. Thanks In any >case you can always speak to a manager to get the case moved to a more >experienced tech. >>so much. > >Art S. Kagel Madison Pruet