csg@pyramid.pyramid.com (Carl S. Gutekunst) (09/09/89)
In article <330845.8909051501@asd.wpafb.af.mil> hassler@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@mirror.UUCP (Barry Roskuski), from article <30529@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>
bob@tinman.cis.ohio-state.edu (Bob Sutterfield) (09/09/89)
In article <83706@pyramid.pyramid.com> csg@pyramid.pyramid.com (Carl S. "UBD" Gutekunst) writes: In article <330845.8909051501@asd.wpafb.af.mil> hassler@ASD.WPAFB.AF.MIL (Barry D. Hassler) writes: ...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... trying to be funny. "Never try to be droll, clever, or subtle on the Usenet." -- unknown