🚀 go-pugleaf

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

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 

"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)

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

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)

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

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.edu

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

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

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.

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

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.

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.

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

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

>>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

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

>	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

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