luner@werewolf.CS.WISC.EDU (David L. Luner) (08/29/89)
In article <175@bally.Bally.COM> dahl@bally.UUCP (Michael Dahl) writes: > >I am confused about the different ways to get help and report bugs for AIX. > > OK -- I'm going to answer this in my "official" capacity as an IBM Systems Engineer. The following information is what I believe to be correct although it has not been through any formal IBM review process (of which there undoubtedly is one). Please mail any corrections (no flames, just post those) to me directly so I can humble myself all at once. >Who do you call for technical support? Technical Support: If you purchased your system directly from IBM, call the Marketing Representative who sold it to you. They should put you in touch with the Systems Engineer at the local branch who is either responsible for your account or generally responsible for AIX systems. If you do not get satisfactory support from this individual, speak with his or her manager. Caution: Systems Engineers are *not* Unix gurus. If the one you are dealing with has a substantial amount of AIX expertise, so much the better. If not -- remember they're not supposed to have intricate knowledge of system internals. They will, however, know how to find out virtually anything you need to know. This takes time. First they may have to understand the problem and then must bring it up through the layers of the IBM support. This can involve many electronic and real phone calls over a number of days. The keys here are patience (I omit an explanation) and planning (don't expect a very detailed problem or question to be resolved the next day -- plan in advance for what you will need to know and when you will need to know it). If you are part of a larger organization, e.g. a university, it may be that your interaction with IBM must be conducted through a local (to your organization) support group. If you find out that your customer number is "not authorized for (software) service", this may be the case. Generally, your customer number will (for the duration of your warranty period and maintenance contract) always get you direct IBM hardware service. If you purchased your system from a dealer or other third party, call the person who sold it to you. When dealers sell machines, IBM pays them money. This is for their sales *and support* efforts. If you do not get satisfactory support from a dealer, you should make this fact known in no uncertain terms to both the dealer and to the Marketing Manager(s) at your local IBM branch. >Who do you call to report defects? Defect Support (Bugs) Bugs are reported to IBM Defect Support at 800-237-5511. The first thing the operator will ask for is your customer number. This number is either on the invoice that came with your machine and/or software or available from your local IBM Marketing Representative. If you purchased your machine from a third party, you are still eligible for IBM Defect Support for those components that are supported by IBM. A customer number you may use with Defect Support should be provided by whoever sold you the system. For example, if you purchased a Fourth-Generation FOO-Code generator as part of a package that included AIX, don't call IBM if the FOO-preprocessor is generating garbage C code. However, if the C code that is generated compiles incorrectly, please do report the problem. This brings us to the distinction between Defect Support and Problem Determination. Using the FOO-Code generator example, your problem may "just" be that an application elicits a "Bus Error -- Core dumped." Generally, IBM Defect Support will not accept a problem until you can provide a testcase that is reproducible in an IBM supported environment. Anything before that point is one of problem determination. Problem determination is a technical support issue (see above). >Who do you call to get fixes for reported defects? This is a technical support issue and should be refered to your Systems Engineer or (third party) vendor. Some people have suggested that you play games and call in "pseudo problems" with Defect Support and use that route to get the "latest fix diskettes". Remember Abigail's Advice: If it ain't broke, don't fix it. If you have a problem, call it in and, more than likely, the most recent patch level for that component will be sent to you. Do not apply patches just because they are available. Regression testing of patches is very difficult and, invariably, they have tested all possible situations *except yours*. If there is a serious problem (e.g. system security or integrity problem), that information will be sent through the existing technical support channels. (See above). >[...APARS vs. defects -- which is faster] APARS are "acknowledged defects". They may be fixed soon, they may be fixed later, they may not be fixed at all. The process for getting problems that are bothering you fixed is a technical support issue. There are procedures for rattling cages up to amazingly high levels until a problem is resolved. Your Systems Engineer will work with you and with the IBM Defect Support group to (hopefully) get things resolved to everyone's satisfaction. Analogous paths exist for those who purchased their systems from third parties. David Luner Systems Engineer IBM Madsion (608) 273-5243
jw@pan.UUCP (Jamie Watson) (08/31/89)
> This takes time. > First they may have to understand the problem Right. So the customer gets to teach Unix to the Support "Engineer" before he can even report the problem. Trying to explain how to setup and use uucp to someone who never even *heard* of uucp before is not my idea of a good time. Pick your favorite non-trivial Unix utility and substitute it for "uucp" here. > The keys here > are patience (I omit an explanation) and planning (don't expect a > very detailed problem or question to be resolved the next day -- plan > in advance for what you will need to know and when you will need to > know it). The real fun comes when you discover that 50 (or 100, or several hundred) other people have also been patient, and planned what they will need to report the *same* bug, and are now waiting for an answer from IBM. As an example, in recent days there have been three different people who have written here about a problem using rlogin from non-RT systems to RT's. I have been struggling with exactly the same problem for a long time. I have been patient, I have invested *huge* amounts of time trying to figure out what is really happening so that I can report this bug. I have had the pleasure of teaching the Support Engineer here what rlogin is ("I only use telnet..."). To top it off, the fact that this only happens from non-IBM systems makes it almost hopeless to report anyway - I have already been told several times that as long as it works between IBM systems, they are really not interested in whether it works from any other system. > Some people have suggested > that you play games and call in "pseudo problems" with Defect Support > and use that route to get the "latest fix diskettes". This might be a game to you, but it certainly isn't to us. We are trying to run a business here. We believe that the job of our software engineers is to write computer programs - not to spend all their time discovering and documenting AIX bugs that have been discovered and documented a hundred times before. Because of IBM's idiotic support policy, we have to go throught a lot of stupid gyrations just to try to find out about previously discovered, and often resolved, bugs. > Remember Abigail's > Advice: If it ain't broke, don't fix it. I'm speechless at the wisdom and insight this brings to the discussion. Of course, Abigail never had to spend her time, or pay anyone else to spend their time, trying to *find out* if it's broke or not, only to discover that lots of other people already knew the answer to that. jw