jw@pan.UUCP (Jamie Watson) (08/07/89)
I recently posted a complaint about aixterm not working correctly with R3 window managers. I got a response by mail from someone at IBM which said that there had been an update last January which fixed this. This was at least the second time that I have posted something to this news group, and then been told that the problem had already been fixed. Due to the IBM's absolutely IDIOTIC policy of not notifying customers of bugs or available fixes, I had no way of knowing that there was a solution to this problem (or any other AIX problem). For those who are not familiar with this piece of trash that IBM calls corporate policy, it goes like this. When a customer calls and reports a problem, the customer support engineer checks a database of previously reported problems. If the same, or very similar, problem has already been reported and fixed, you hit the jackpot! The grand prize is an update diskette which (maybe) fixes your problem. This policy leads to a situation where customers constantly feel they are missing out on updates, so they start calling IBM support and playing "20 questions". The customer says "I have a C compiler problem"; the support person says "What kind of problem"; the customer says "I'm not sure; what kind of bug fixes have you got for the C compiler". Then they go on down the list. Great fun. Unfortunately, the people who work in IBM customer support are not the most knowledgeable Unix experts in the world, so it is frequently difficult to get them to understand exactly what you are reporting and how to duplicate it. As a case in point, I tried to report some uucp problems not long ago. I found that the support engineer I was talking to had never even *heard* of uucp; so I had to try to explain how to set up and use uucp before I could even start on the bug report. Not exactly a good time... Then, just to top things off, the people working in Austin who are supposed to support the customer service engineers have recently discovered a new response to virtually any bug report - "That's not a bug, it's a documentation error." For example, I recently discovered a bug in the C complier; the %c conversion in scanf skips white space. After several weeks of discussion and debate, the answer came back from IBM Austin that this was a "documentation error". It was only after we showed them that the C compilers on DOS and OS/2 didn't have this bug that they broke down and admitted that it was a bug, and said that they would fix it. I'm still waiting for the fix... jw
buck@siswat.UUCP (A. Lester Buck) (08/09/89)
In article <550@pan.UUCP>, jw@pan.UUCP (Jamie Watson) writes: > > For those who are not familiar with this piece of trash that IBM calls > corporate policy, it goes like this. When a customer calls and reports > a problem, the customer support engineer checks a database of previously > reported problems. If the same, or very similar, problem has already > been reported and fixed, you hit the jackpot! The grand prize is an > update diskette which (maybe) fixes your problem. This policy leads > to a situation where customers constantly feel they are missing out on > updates, so they start calling IBM support and playing "20 questions". > The customer says "I have a C compiler problem"; the support person > says "What kind of problem"; the customer says "I'm not sure; what kind > of bug fixes have you got for the C compiler". Then they go on down > the list. Great fun. Since the defect support people are not very technical, the first thing they do is say "We will send you the latest updates overnight. See if these fix your problem." So we effectively blow two more days before they even start to think about our problem, as well as wasting our time checking that, yes, that bug is still there after the latest slew of updates. Just hope everything else still works after all these updates are applied, since you can't back out changes once they are accepted. For example, we once had something similar to an updatep disk with fixes to uucp updating the Fortran compiler to the latest level, while breaking something in Fortran that had previously worked. And this idiotic policy extends even to security bugs, as a previous posting of mine in this group demonstrated. The main effect of this quiet update policy is that customers learn to call every week or two and demand the latest update disk, whether they are having problems or not. I have better things to do than rediscover the same bugs in AIX/RT that someone else found weeks ago. When is the quintessential marketing company going to wake up and listen to their customers? Maybe when the promised nirvana of the follow on RT falls flat on its face due to policies like this... -- A. Lester Buck ...!texbell!moray!siswat!buck
drake@ibmarc.uucp (Sam Drake) (08/09/89)
I'm not an official spokesman, so ignore anything I say below. Things aren't quite as bad as portrayed in the earlier append. For example, when calling Support you don't have to "play 20 questions" to get the latest service; simply say, "I want a copy of the latest service for xyz" and they will send it to you. Update diskettes seem to come out every few weeks, and they are cumulative. I've had good results with this for years with AIX support, and internal IBMers historically have had to go through the exact same process as customers do to get fixes. Sam Drake / IBM Almaden Research Center
gors@well.UUCP (Gordon Stewart) (08/10/89)
"Welcome to the party, pal..."
The official line I got when I complained of this IDIOTIC policy was
that these bug fixes aren't guaranteed (what is? Every piece of software
they sell has a warranty disclaimer!) and that they should be distributed
to people having the problems.
The new release (whenever the @#$*! that appears) will incorporate all
these lovely, wonderful fixes.
If there's anyone at IBM listening, get a copy of <550@pan.UUCP> to
your boss, your boss's boss, etc. !!! It's about time IBM got with
the rest of the UNIX world!
The support structure is inappropriate for UNIX folks -- they really
MUST establish a whole new ball of wax, unless they want to be forever
condemned to a MINISCULE market share in UNIXdom.
As Scott McNealy says, System V is "Coca-Cola Classic" -- AIX is some
supermarket brand.
--
{apple, pacbell, hplabs, ucbvax}!well!gors
gors@well.sf.ca.us
(Doolan) | (Meyer) | (Sierchio) | (Stewart)karish@forel.stanford.edu (Chuck Karish) (08/10/89)
In article <13071@well.UUCP> gors@well.UUCP (Gordon Stewart) wrote: [ IBM doesn't send out AIX patches unless asked. ] >If there's anyone at IBM listening, get a copy of <550@pan.UUCP> to >your boss, your boss's boss, etc. !!! It's about time IBM got with >the rest of the UNIX world! Where's this `rest of the UNIX world'? I haven't seen unsolicited patches from either DEC or SCO, except for security fixes for the bugs highlighted by the fiasco last November. Convex seems to be somewhat more cooperative, but I only know of their policies from the point of view of a customer site that's provided them with a lot of help in finding bugs in their OS. Chuck Karish {decwrl,hpda}!mindcrf!karish (415) 493-9000 karish@forel.stanford.edu
gors@well.UUCP (Gordon Stewart) (08/11/89)
In article <990@ks.UUCP> drake@ibmarc.UUCP (Sam Drake) writes: >I'm not an official spokesman, so ignore anything I say below. > >Things aren't quite as bad as portrayed in the earlier append. For example, >when calling Support you don't have to "play 20 questions" to get the >latest service; simply say, "I want a copy of the latest service for xyz" and Sam, Sam... This presumes that you know what corrective service you need. What we are complaining about is IBM's series of hoops -- technically, we're supposed to post a query to IBMLINK (dreck!!), then go through our SE, or possibly Product Support, Defect Support, wait by the phone for a call-back, etc. WHY THE @#$% CAN'T THEY SIMPLY POST THE LATEST BUG REPORTS AND MOST RECENT VERSIONS OF THE FIXES TO A MEDIUM LIKE THIS ONE -- INSTEAD OF WASTING WEEKS (LITERALLY) OF MY PRECIOUS TIME ON INCREMENTAL PROBLEM FIXES!!!???? The biggest burden is that, for a straightforward technical problem, I usually have to speak to a minimum of three people before the one person in AUstin who knows what I'm talking about calls me. It's every bit as bad as we say -- And the problem is a policy one -- there are plenty of competent, eager-to-help support people at Big Blue -- the process of getting to them is AWFUL! Maybe this crap works for most of IBM's products -- but they're in OUR ballpark now, and they need to listen to us. If I didn't care, I wouldn't carp -- but I can't seriously recommend an RT running AIX over a SUN, Apollo, HP -- it would be last on my list. And it's a shame, since the hardware is great. As my uncle Luigi says, "The Shpaget's good -- the sauce, a little strange.." -- {apple, pacbell, hplabs, ucbvax}!well!gors gors@well.sf.ca.us (Doolan) | (Meyer) | (Sierchio) | (Stewart)
luner@werewolf.CS.WISC.EDU (David L. Luner) (08/11/89)
In various articles, everybody and their dog writes: > > "I'm unhappy with IBM's delivery of fixes" [ed.] > I am curious, both personally and as an IBMer, to hear what other vendors to support their code. I *don't* want this to become a "we want source" argument. Just tell me what other vendors to in an OCO (Object Code Only) environment. For example, are fixes regularly mailed? How often? Does someone provide automatic electronic fixes (e.g. call up your system and install the patch)? Do they charge for software maintenance? For what it's worth, 1. If you *mail* me, I'll summarize 2. I'll pass on the summary to IBM (though I find it hard to believe they haven't taken such a survey already) through the Market Requirement channels. [If it ends up in the circular file, at least I tried.] David Luner Systems Engineer IBM Madison 608-273-5243
dyer@spdcc.COM (Steve Dyer) (08/11/89)
Using SCO as a typical UNIX System V vendor, I can state that they
do not have a policy of distributing bug fixes to all supported
customers, yet the sentiment about the quality of their support
is generally quite positive. I wonder why? First, they have
relatively frequent minor releases encompassing all bug fixes;
second, their support team is skilled and responsive.
I think if customers do not have faith in the quality of the
support service to begin with, then they will focus on minutiae
such as not being sent bug fixes immediately, when in fact it
indicates a more general dissatisfaction.
--
Steve Dyer
dyer@ursa-major.spdcc.com aka {ima,harvard,rayssd,linus,m2c}!spdcc!dyer
dyer@arktouros.mit.edujw@pan.UUCP (Jamie Watson) (08/15/89)
In article <8147@spool.cs.wisc.edu> luner@werewolf.CS.WISC.EDU (David L. Luner) writes: >In various articles, everybody and their dog writes: >> >> "I'm unhappy with IBM's delivery of fixes" [ed.] >> > >I am curious, both personally and as an IBMer, to hear what other vendors >to support their code. I *don't* want this to become a "we want source" >argument. I don't want source. I just want to know about bugs that have already been discovered in my binaries, and fixes that are already available for those bugs. I don't want to have to waste my time re-discovering, and tracking down, and documenting, and reporting, bugs that have already been discovered, and tracked down, and documented, and reported, and in many cases fixed. My employers aren't paying me to do that. > 1. If you *mail* me, I'll summarize No thanks, I want this discussion to stay in an *open* forum. If there is anyone else who has anything to say, I want to see it. - H-P sends out a listing of known bugs in HP-UX. It is *very* thick, I've heard as much as several hundred pages, and it comes out pretty often, I've heard as often as monthly. - Plexus (R.I.P) used to send out a software support newsletter from time to time, which included a list of known bugs in their O.S. - A few years ago, when I worked for the Sun distributor in Switzerland, Sun used to send out technical bulletins with known bug lists. I don't know if they do any more or not. (From what I heard about SunOS 4.0, they would have had to hire a truck to deliver it to each customer...) jw
tom@stiatl.UUCP (Tom Wiencko) (08/15/89)
In article <550@pan.UUCP> jw@pan.UUCP (Jamie Watson) writes: >discovered a new response to virtually any bug report - "That's not a >bug, it's a documentation error." For example, I recently discovered > >jw This is not the best one. Back in the days when I used to submit a lot of APARs (Authorized Program Analysis Reports, aka bug reports) IBM had a classic way of closing a report they did not want to fix. You ready for this? Better sit down. "We are closing your APAR as an undocumented restriction." Great. Tom
rg@psgdc (Dick Gill) (08/18/89)
More real life experience with other vendors: I recently received an unsolicited phone call from NCR Tower support alerting me to a known OS problem with multi-volume backups. It made me feel good that my clients and I were being well protected against at least some of those nasty OS bugs that plague all vendors.
gregn@cadovax.UUCP (Greg Noel) (08/22/89)
In article <6473@stiatl.UUCP> tom@stiatl.UUCP (Tom Wiencko) writes: >This is not the best one. Back in the days when I used to submit a lot of >APARs (Authorized Program Analysis Reports, aka bug reports) IBM had a classic >way of closing a report they did not want to fix. You ready for this? Better >sit down. > >"We are closing your APAR as an undocumented restriction." > There is a problem with AIX (2.2.x), when you make an open call to open the parallel printer port you get back a file identifier, no matter the state of the printer (let's say Nebraska). The open call will NOT fail. After talking to support and four weeks I got a call back: "We are closing your APAR as an permanent undocumented restriction." The write to that file identifier creates a whole other set of problems... -- Greg Noel [Gn] Versyss, inc., Torrance, Ca. Nothing Works, and Nobody Cares. -W Allen
tom@stiatl.UUCP (Tom Wiencko) (08/22/89)
In article <2408@cadovax.UUCP> gregn@cadovax.UUCP (Greg Noel) writes: >>In article <6473@stiatl.UUCP> tom@stiatl.UUCP (Tom Wiencko) writes: >>>"We are closing your APAR as an undocumented restriction." >>"We are closing your APAR as an permanent undocumented restriction." IBM is nothing if not consistant. Why am I not surprised? (heavy sigh) Tom -- Tom Wiencko (w) (404) 977-4515 gatech!stiatl!tom Wiencko & Associates, Inc.
whm@sunquest.UUCP (Bill Mitchell) (08/25/89)
In article <550@pan.UUCP>, jw@pan.UUCP (Jamie Watson) writes: > > Then, just to top things off, the people working in Austin who are > supposed to support the customer service engineers have recently > discovered a new response to virtually any bug report - "That's not a > bug, it's a documentation error." ... I had the same thing happen recently with a dbx bug. If you have a C function in a #include file, dbx doesn't know to use the include file as its source of source lines to display -- it just uses the previous file. I reported this, and after a couple of weeks they said that they'd filed a bug report. Against the documentation. If that's not bad enough, they don't accept examples of bugs via electronic mail, so we had to mail a floppy with a 14-line program on it. I pressed this issue with our SE and later got back to me with "our legal department is looking into it...". -------------------------------------------------------------------- Bill Mitchell whm@sunquest.com Sunquest Information Systems sunquest!whm@arizona.edu 930 N. Finance Center Dr. {arizona,uunet}!sunquest!whm Tucson, AZ, 85710 602-885-7700
karish@forel.stanford.edu (Chuck Karish) (08/25/89)
In article <187@sunquest.UUCP> whm@sunquest.UUCP (Bill Mitchell) wrote: >I had the same thing happen recently with a dbx bug. If you have a C function >in a #include file, dbx doesn't know to use the include file as its source >of source lines to display -- it just uses the previous file. I reported this, >and after a couple of weeks they said that they'd filed a bug report. Against >the documentation. So, don't put functions into header files. They belong in .c files. Lint has problems finding some initializations, too, but it usually puts in a question mark after the file name, at which point the programmer has to pre-process the source to find out what's going on. >If that's not bad enough, they don't accept examples of bugs via electronic >mail, so we had to mail a floppy with a 14-line program on it. They accept them by FAX, if you call them first so there's someone assigned to the problem. Chuck Karish karish@mindcraft.com (415) 493-9000 karish@forel.stanford.edu
dahl@bally.Bally.COM (Michael Dahl) (08/29/89)
>>This is not the best one. Back in the days when I used to submit a lot of >>APARs (Authorized Program Analysis Reports, aka bug reports) IBM had a classic I am confused about the different ways to get help and report bugs for AIX. Who do you call for technical support? Who do you call to report defects? Who do you call to get fixes for reported defects? How does one submit an APAR? Is it better to submit APARS or call in defects? Which way is faster? Could someone who understands these processes please post an explanation of how all this works. Thanks in advance. Michael Dahl uucp - uunet!bally!dahl Bally Systems domain - dahl@bally.bally.com 255 Bell Street Phone (702) 323-6156 x882 Reno, NV 89503 FAX (702) 323-5997
whm@sunquest.UUCP (Bill Mitchell) (09/01/89)
In article <4830@portia.Stanford.EDU>, karish@forel.stanford.edu (Chuck Karish) writes: > In article <187@sunquest.UUCP> I wrote: > >I had the same thing happen recently with a dbx bug. If you have a C > >function in a #include file, dbx doesn't know to use the include file as > >its source of source lines to display ... > > So, don't put functions into header files. They belong in .c files. > ... I agree that putting C functions in header files is non-standard, but in this case, some code being ported from VMS has some C code in header files. My opinion is that if you can compile it, you should be able to debug it. > >If that's not bad enough, they don't accept examples of bugs via electronic > >mail, so we had to mail a floppy with a 14-line program on it. > > They accept them by FAX, if you call them first so there's someone > assigned to the problem. For this dbx bug, I did send a FAX to the support person after the initial contact, but she insisted on a floppy. -------------------------------------------------------------------- Bill Mitchell whm@sunquest.com Sunquest Information Systems sunquest!whm@arizona.edu 930 N. Finance Center Dr. {arizona,uunet}!sunquest!whm Tucson, AZ, 85710 602-885-7700