Path: utzoo!news-server.csri.toronto.edu!bonnie.concordia.ca!ccu.umanitoba.ca!herald.usask.ca!alberta!ubc-cs!uw-beaver!cornell!llenroc!batcomputer!caen!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!pacbell.com!ucsd!hub.ucsb.edu!appmag!pa
From: pa@appmag.com (Pierre Asselin)
Newsgroups: comp.unix.aix
Subject: Re: Making A request to IBM (Was: Re: How does one compile to assembly?)
Message-ID: <1991Mar14.031806.3002@appmag.com>
Date: 14 Mar 91 03:18:06 GMT
References: <13111@darkstar.ucsc.edu> <1991Mar6.211740.25556@ibmpa.awdpa.ibm.com> <96@softpro.stgt.sub.org> <1991Mar13.184439.6999@ibmpa.awdpa.ibm.com>
Organization: R&D, Applied Magnetics, Goleta, CA
Lines: 61

jsalter@ibmpa.awdpa.ibm.com writes:

>In article <96@softpro.stgt.sub.org> cmo@softpro.stgt.sub.org (Christian Motz) writes:
>>In article <1991Mar6.211740.25556@ibmpa.awdpa.ibm.com> jsalter@slo.awdpa.ibm.com (Jim Salter) writes:
>>>Please feel free to call up IBM with requests
>>>for it, though.  If enough people want it and *communicate* this to IBM,
>>>it might get in there.
>>The big problem I (and I suppose quite a lot of people) have with this is
>>that I don't have the slightest idea where and how I should make these
>>kinds of requests.

>Well, there is supposed to be an 800 phone number that everyone gets.  And
>you should have an ID number to identify yourself.  Your SE/CE should know
>what this number is.  Look, IBM has gone to A LOT of trouble to put together
>a support structure to satisfy you, the customer.  In fact, from comments
>I've seen in the trade mags, IBM's support is better than of older, more
>established *IX companies.
>[...]

Don't believe everything you read [ 1/2 :-) ].  The two numbers I have are
  800-237-5511  IBM Software Defect Support
  800-426-7378  IBM Hardware Defect Support
The first is for bug reports, the second is for replacement parts.
Neither is a tech hot-line.  It's a good idea to check with Software,
in case your bug is already known and has a fix, but that's the exception,
not the rule.  Unless the origin of the problem is obvious, call your CE.
Mine is phenomenally competent, but he has enough work for ten.  The system
doesn't work too well here.

>DOCUMENTATION: If you're confused by how to do something you're probably not
>the only one, call it in;
>USABILITY: if you can't use something, or it doesn't work as documented,
>call it in;
>ERROR MESSAGES: if the error message is more confusing than the error,
>call it in;
>PERFORMANCE: if the same thing works 5 times faster on a Sun 3/50,
>CALL IT IN! :-)

Software Defect Support is *not* the place to call.  They handle specific
bugs, not across-the-board disasters like these.
(Yeah, the number-crunching is good.  And we don't need super graphics.)

>DESIGN.: If something is designed wrong (like the malloc() controversy),
>and you want to see it changed, call it in; (this probably entails a few more
>levels of beuracracy, though, and there has to be enough customer support
>to justify changing it...)

I believe the magic words here are ``DESIGN APAR''.  Then they have to
listen to you.  I submitted a design apar for this very same malloc;
they want an example of broken code(!)  OK, we'll see, stay tuned...
NB: This malloc madness is not an IBM exclusivity.  Claims that this
    bright idea comes from SYSV may be true, denials notwithstanding.

>>                              Christian Motz, cmo@softpro.stgt.sub.org

>jim/jsalter  IBM PSP, Palo Alto  T465/(415)855-4427  VNET: JSALTER at AUSVMQ
>Internet: jsalter@slo.awdpa.ibm.com         UUCP: ..!uunet!ibmsupt!jsalter 
>  PS/2 it, or DIE!  :-)  The ramblings above have nothing to do with Big Blue.

Pierre Asselin, R&D, Applied Magnetics Corp.  I speak for me.
3003jalp@ucsbuxa.ucsb.edu     (soon pa@appmag.com)