The Quality of Pyramid's Service [LONG]

[Carl S. Gutekunst]

In article <330845.8909051501 at asd.wpafb.af.mil> hassler at ASD.WPAFB.AF.MIL (Barry D. Hassler) writes:
>I currently am pleased with RTOC's support for the most part....

Nice to see *someone* willing to admit this. :-)

>However, by the tone of some of the other responses to this subject thread,

What "tone" ? Not to trivialize their very real complaints, but only *two*
people have complained. (The only other poster in this thread was Mark Dia-
mond from Sequent, who was making some general (and pompous, albeit correct)
observations on the arrogance of software designers.)

There is an issue here that the overwhelming majority of Pyramid's customers
are commercial sites, and few of those have Usenet access. The sites running
Pyramids on the net do not provide anything resembling a reasonable cross
section of the customer base. 

>maybe they are just treating the organization for which I work differently
>(Control Data/IIS is a large VAR of Pyramid with installed systems scattered
>across the country, and for which we are responsible for administration and
>on-site support). 

I don't think so. RTOC and Sustaining have long tended to treat all customers
the same, big and small, even when it would have been "politically correct"
to do otherwise. While you can support this on moral grounds, it is tough to
support on practical bottom-line grounds. For example, I know from my own
observation that Sequent provides much better support to customers who also
have a Pyramid system than they do to their regular customer base. Pyramid
ignores such things. Should Pyramid do the "politically correct thing"? You
decide.

>Tom Reingold complained in his original posting that he constantly has to
>hound RTOC to follow up on problems, and Carl Gutekunst agrees this is the
>"right" thing to do. 

*SIGH* I never said this was "right." I said it could be helpful. As Scott
suggested, it's the ol' squeaky-wheel syndrome. And remember, this is *NOT* a
push on RTOC or Sustaining Engineering, it's a push on R&D. And I am going to
be talking to appropriate people about how to mechanize this process, so that
R&D gets pushed automatically, and the customer gets notified automatically.

>Maybe I'm lucky, my "rep" inside RTOC... does follow up with me. When I am in
>a "critical stage"... they generally follow up on the order of at least once
>per day. This should be the norm - 

It should be. And I believe it is.

>Working with Users as I do occasionally, I must agree  that  MANY  problems
>are  really  just  User  Brain  Damage  (to  quote  Carl  Gutekunst).

Arggh. I'm an *never* going to live that one down? I was wrong for saying it,
and it was my personal choice of terms, trying to be funny. It is not the
opinion of RTOC. There are no employees *still working for Pyramid* who have
either called a customer "stupid" or implied that they were. (I didn't coin
the term "stupid users"; that was Mark Diamond.)

On to roskuski at mirror.UUCP (Barry Roskuski), from article <30529 at mirror.UUCP>:
>>Assuming that you made a mistake, and trying to figure out what, is not
>>only a human reaction, but it will be accurate and get the problem fixed 
>>very quickly most of the time.
>
>This is an extremely dangerous assumption to make. This is a great way to
>turn off the customers that *do* know what they are doing.

Well, yeah, I said that. It's a risk. The diplomatic way to go about this is
to assume that the customer described the problem correctly, and work with
him or her to figure out what's actually wrong. As I already pointed out, UNIX
has horrible error recovery, and is very prone to taking entirely unreasable
actions in response to "user error."

>I sat for about an hour watching an RTOC engineer remotely dialed in to my
>system duplicating the EXACT same steps I had told him I had done to diagnose
>the problem and getting the EXACT same results I reported to him. Is that
>getting the problem fixed as quickly as possible?

It most certainly is. In doing so, the RTOC engineer did three very important
things: he established that the problem was repeatable; he verified with you
that he understood the problem; he got a script of the behavior of *your*
machine, in case it came out differently on the machines here. As an inciden-
tal matter, he also verified that you described the problem correctly in the
first place, though we can assume that part wasn't necessary. The other were,
and had nothing at all to do with your competance.

>Are we one of those who have cried wolf?

That's not a formal designation :-), so I don't know. Mirror has had a number
of problems off and on, some ours, some due to an overly optimistic salesrep,
and some due to overly optimistic management at Mirror. (Sorry, folks, but you
just can *not* use dump(1) on an NFS partition. :-)) 

>RTOC would not look at them blaming everything on our bad power. We got the
>bad power fixed, and low and behold THE SAME PROBLEMS WERE STILL THERE!!!!

Um, but you admit you *did* have bad power?

"Bad Power" was a magic cookie around here for a while. We had several major
accounts that we tore our hair out trying to fix, until we discovered that all
the problems were, in fact, bad power. (And we're talking *really* bad. We had
a similar problem in our lab. The fact that we were going through Wyse 50
terminals like kleenex should have tipped someone off.) As a consequence, RTOC
is a little learly of spending a lot of time trying to diagnose problems when
it is known that bad power is present.

There's also our "prophet of power," Bruce Davis at SouthWest Bell, who will
happily talk for *hours* on his strategies for power distribution and power
grounding. It's hard to argue; his machines have zero downtime for years at a
time.

Incidentally, the MIServer has a new power supply, and is *much* more tolerent
of bad power. Most recently, we had a surge that stalled the air conditioning,
and crashed most everyone's terminals. Many of the old 90x and 9800 series
went down, too. The MIServers didn't even notice.

>I understand that yes, the customer is wrong a good deal of the time....

I never said that. I said it will probably be a *user error.* A very different
thing. Indeed if you approach all problems assuming that the user is brain-
damaged, you'll be inclined to treat him or her like a fool. If you assume
that they may have a problem that they don't understand, you'll treat them
like a customer.

<csg>