Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!ux1.cso.uiuc.edu!resnick
From: resnick@cogsci.uiuc.edu (Pete Resnick)
Newsgroups: comp.unix.aix
Subject: Re: Making A request to IBM
Message-ID: <1991Mar22.181533.21699@ux1.cso.uiuc.edu>
Date: 22 Mar 91 18:15:33 GMT
References: <1296@dkunix9.dk.oracle.com> <1991Mar15.123532.8036@odi.com> <5958@awdprime.UUCP> <3300@pensoft.UUCP>
Sender: usenet@ux1.cso.uiuc.edu (News)
Organization: University of Illinois at Urbana
Lines: 77

I first want to thank Robin for his last two postings. It did clarify
some stuff. I have dealt with Robin for a couple of defects I have
reported, and he knows what he is talking about. I think, however,
this method of defect support for Unix workstations is just bad policy
on the part of IBM. This is exactly the kind of support you want for
VM machines, where the customer is usually totally dependent on IBM
for it's system software and is usually running a limited number of
different system level programs. But in a Unix workstation environment
when you have 15 programs off the network and system administrators
like me who need to get software working without having to call IBM
at the drop of a hat, this is really unacceptable.

Officially, I have to deal with my SE first. I don't. Chances are
my SE doesn't know any better what is going wrong than I do, and
can not just drop by in the next hour all the time to help. No doubt,
once when I was really hung using IBM's updatep program (more to say
about this later), my SE was great; but for 99 percent of the problems
he does not have the resources to be effective.

So I call defect support when I have a problem that is a defect. I
have had both good and bad experiences here. The problems that I have
had stem basically from the fact that there is a policy to have the
customer talk to level 2, and have level 2 talk to level 3. Half,
and only half, the time this works. The problem is that there is a
high probability that I know more about the problem and where to
look for an error than any given level 2 person on any given problem.
If I was on the phone with level 3, as finally happens after weeks
of back and forth conversations sometimes, diagnosis would speed
up incredibly. As it stands now, I have to try and convey all of the
information I can to a person at level 2 (inevitably losing some in
the translation from me to level 2 and level 2 to level 3) and wait
for someone to figure out something that would be found out in 10
minutes if the level 3 person would walk me through a diagnosis on
the phone. I *know* that there are cases where this would bog down
level 3 incredibly. I am claiming that a good deal of the time, this
would speed up the process.

Sometimes, level 2's diagnosing techniques are annoyingly rote:
if you have a TCP/IP problem, someone is going to ask your for
your /etc/hosts file. Not that it has anything to do with the
problem, but they ask for it anyway. I have heard the same questions
20 times for a lot of defects because some, and only some, level 2
people are not asking logical questions; it sounds like they read out
of a manual. I have had good experiences with people at level 2,
but the bad ones stick out more.

Then, once a problem is addressed, I get an update. I get a disk
that says "Use updatep command", no clue of what is ever being
changed, no bug fix list except the APAR list, nothing. Not only
that, I only get updates when I ask for them, and the production
to install them borders on the unbelievable. Again, this method
is great for a VM machine, but not for a Unix machine that I am
taking care of. I want to know what's happening, and be able
to back off if I need to. (*No, applying updates without comitting
them does not always work, and you can not do more than one
change, test them together and then reject.*)

IBM's defect support is not oriented for Unix workstations. This
is a problem of philosophy. It takes alot of change to get me
to talk live to a "level 3" type person quickly, but that is what
is necessary in most cases. I think the savings of time and money
would be incredible.

End of pontification. Thanks again to Robin, one of the level 3
people I have actually talked to, and the bunch of level 2's that
have helped me in the past. This is certainly not a flame of the
people in defect support; most of them are rather smart people.
This is a flame of a system that is just poorly operated for a
product that it was never designed for.

pr
--
Pete Resnick             (...so what is a mojo, and why would one be rising?)
Graduate assistant - Philosophy Department, Gregory Hall, UIUC
System manager - Cognitive Science Group, Beckman Institute, UIUC
Internet/ARPAnet/EDUnet  : resnick@cogsci.uiuc.edu
BITNET (if no other way) : FREE0285@UIUCVMD