Re[2]: Informix Tech Support?

Art has some interesting points about knowing the priority levels. However, I have never used that approach and still feel that I get good support when I call. Sometimes you do have to explain to them that this is critical because.... and I think that is another part of "knowing how to play the game...". Also, you can never give them too much information. I have observed others who have called and said something like, "We are having a problem and I think it's because of X." This can lead someone down the wrong road immediately. If you're calling the hotline, you should describe to them what you or your users are doing and let them ask all of their questions to narrow it down. (Example using my company: The other day we had slow logins and someone called our assistance center saying we had slow logins and they think it is the network. This got the network group involved and nothing was wrong with the network. An nfs mount was messed up on the server. A system admin should have been given this call first and it would not have gone any farther. And it would have been resolved a lot quicker.) So even when I have an idea of where the problem is, I try to let them go through their checklist of things. Dianne ______________________________ Reply Separator _________________________________ Subject: Re: Informix Tech Support? Author: "Art S. Kagel" <kagel@bloomberg.com> at INTERNET Date: 4/1/98 6:13 PM Ray Garrison wrote: > > In article <6fu6ol$d28$1@news.xmission.com>, > "John S. Michael" <john.michael@flyingj.com> wrote: > > >Roger Tomas wrote in message <352291C9.D4DD7C06@agcs.com>... [SNIP] > >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. In any case you can always speak to a manager to get the case moved to a more experienced tech. Please remember patience, we all had to learn what we know. Techs who have driven me crazy by their lack of knowledge when they first started are amoung my favorite support people today because they have learned so much. Art S. Kagel