mag@whuxlm.UUCP (Gray Michael A) (02/01/85)
> Having the unenviable job as machine coordinator for 6 of the > VAX 11/780s at the Denver AT&T site, I have been extremely > frustrated by the high amount of downtime our > machines have been experiencing. One VAX has been up less > than 50% of the time over the last 3 months. These machines [..] > Secondly, DEC seems to be slow to escalate the problem if > a solution is not readily apparent to the personnel > on site. Being a hacker of sorts I understand the old ....... We have one or two of just about any machine DEC has ever made in our Department at AT&T Bell Labs. While I don't feel that the DEC servicepeople are real fireballs, our downtime is nothing like yours. It's certainly less than 15%. The DEC machines that we use to run our product in the field (a database system that does some number-crunching for a test system) average less than 2 hours downtime per week. By the way, I know this isn't net.jokes, but: Q. How can you tell if a person with a flat tire at the side of the highway is a DEC repairman? A. He's the one that is changing all four tires to find the flat. Mike Gray, BTL, WH
miles@vax135.UUCP (Miles Murdocca) (02/01/85)
I understand your frustration with hardware/software problems. I too was plagued with problems while maintaining 2 VAXes at a site in Holmdel. But what I found was that DEC was more than helpful in solving our problems. A brand new 750 crashed every day around 2:00am. DEC tried all kinds of things including replacing boards, but nothing worked. Finally, a new set of PROM's were made up by the system designers and all was OK. We had a DR11-B "look-alike" sold by Ramtek that we suspected had failed. It was not under service contract with Ramtek (or DEC) but the DEC site people offered to run their diagnostics on it anyway (they said it would help them to make sure the problem wasn't elsewhere in the machine). The site personnel still help out in formatting new disk packs, as an "instructional" part of their job even though we buy packs from Nashua and drives from System Industries. Here at AT&T Bell Labs in Holmdel, there are over 200 systems under service contract from DEC. Because of the size of our location, it may be easier for them to give continued good service. But it hasn't been all rosy either. We had an 11/40 that was not under contract and it took forever to get repairs made. A tape drive on an 11/45 went dead and it wasn't fixed after 5 fulltime days of DEC personnel working on it (no one was very familiar with such an "old" drive). The field service manager made contact with me a few times a year as I'm sure is the practice elsewhere. I would suggest you contact your field service manager if you are having many troubles. There is no reason to settle for poor service when we pay so much for it! - Miles Murdocca 4B-525 AT&T Bell Laboratories Crawfords Corner Road Holmdel, NJ 07733 (201) 949-2504
ron@brl-tgr.ARPA (Ron Natalie <ron>) (02/01/85)
> I can't understand why DEC doesn't have diagnostics which > run under UNIX and give meaningful results, after all a > portion of the community does run UNIX on their VAXs. > Although they don't have UNIX diagnostics, they are unable to fix the problem using the VMS and standalone versions. > Secondly, DEC seems to be slow to escalate the problem if > a solution is not readily apparent to the personnel > on site. DEC has a rather inane approach to new user training. Rather than putting new people in an apprentice position to an experienced engineer they just send him out cold as the first line support and if he can't fix it in a day, he is supposed to call for help. These first line servicemen are constantly breaking more than they fix. > Is this problem pretty widespread and if so are there any > reasonable solutions? > Another one of their fiascos was that they replaced the floppy drive in a 780 twice before realizing that the floppy disk itself wasn't even one for the VAX (it was UNIVAC microcode). We don't let the DEC people on site except for machine installation (and they can't do that any better). We won't even let this one person in the room (she's by far the worst). Fortunately, she zapped her self good trying to PM one of our VMS machines, and went out on disability. -Ron
mark@tove.UUCP (Mark Weiser) (02/02/85)
We have had pretty good experiences with our DEC service. Our regular
service man ("Dangerous Dan") is actually popular because (a) is he
not here all that often, and (b) he fixes things quickly or finds someone
who can or helps us develop a workaround even if it is not strictly by the
book, and (c) he has a light-hearted approach to Unix, rather than thinking
of it as the enemy.
--
Spoken: Mark Weiser ARPA: mark@maryland Phone: +1-301-454-7817
CSNet: mark@umcp-cs UUCP: {seismo,allegra}!umcp-cs!mark
USPS: Computer Science Dept., University of Maryland, College Park, MD 20742roy@phri.UUCP (02/03/85)
> > ..... I have been extremely frustrated by the high amount of downtime our > > machines have been experiencing ..... Secondly, DEC seems to be slow to > > escalate the problem if a solution is not readily apparent to the personnel > > on site ..... I really have no complaints about our local DEC field service (NYC). When I came here about 5 years ago, we had 3rd party maintenance -- now THAT was a disaster. A few things I've learned about dealing with Field Service: Tell them what they need to know -- don't hide screw-ups. We once snagged a Unibus cable trying to fix something ourselves. I told them what happened, and they fixed it. If you have a reasonable branch manager (we do) s/he will realize that bailing you out is cheaper than having you hide the problem and waste his techs' time trying to find it. Watch, observe, be aware of what's going on, make suggestions if you REALLY think you know something they don't, but don't get in the way (I had a LOT of trouble learning this one). If you have a problem with a particular technician, request that that particular person not be assigned to your site. Let them break someone else's machine. Let's face it -- I've seen some techs who I wouldn't trust to sharpen my pencils. When the techs finally get your machine running again, let them know you appreciate it. Scratch them behind the ears or give them a nice warm bowl of milk. -- The opinions expressed herein do not necessarily reflect the views of the Public Health Research Institute. allegra!vax135!timeinc\ cmcl2!rocky2!cubsvax>!phri!roy (Roy Smith) ihnp4!timeinc/
lda@bonnie.UUCP (Larry Auton) (02/03/85)
> We don't let the DEC people on site except for machine installation > (and they can't do that any better). We won't even let this one > person in the room (she's by far the worst). Fortunately, she zapped > her self good trying to PM one of our VMS machines, and went out on > disability. Don't be so quick to "shotgun" all of DEC field service with remarks like that. In some cases, your dead wrong. We have had our share of problems with getting things fixed. We've also dealt with inexperienced field service personnel. BUT, most of their field service people here at AT&T Bell Laboratories in Whippany are (1) competent, (2) well trained, (3) prompt, and (4) considerate. Most of our problems are fixed quickly, and with NO HASSLE. For example, we added a CPU expansion cabinet and three RA81 drives to one of our VAX-11/780's a couple of weeks ago. The job required moving the unibus expansion cabinet (yuk), a tu77, and an rm05; dual porting an rm05; installing the CPU expansion cabinet, and the ra81 stack. We were scheduled for 5:30pm. DEC arrived at 5:25pm, and got right to work. As the evening progressed, we came up a foot short on the massbus cable for the rm05. DEC had another cable there in 15 minutes! The whole job was complete by 1:00am. There have been NO PROBLEMS with that system since that time. Next time think twice before you blast all of DEC's field service. Some of them are experts! -- Larry Auton (201)386-4272 ihnp4!bonnie!lda
jsq@ut-sally.UUCP (John Quarterman) (02/04/85)
I'd like to actually put in a good word for DEC.
The last time our VAX-11/780 crashed due to memory cache problems,
I called their remote diagnostic center in Colorado Springs. They
asked for and got a guest account on our 4.2BSD system, and dialed
it up by the usual number (not the special DEC diagnostic line).
The engineer looked at /usr/adm/messages, decided on the exact
board needing swapping, and informed our local field office.
All within a couple of hours and without ever taking the machine
down or running diagnostics. It was the right board, too.
They've gotten better, at least in remote diagnosis.
The local reps have mostly gotten over their UNIX-phobia, as well.
--
John Quarterman, CS Dept., University of Texas, Austin, Texas 78712 USA
jsq@ut-sally.ARPA, jsq@ut-sally.UUCP, {ihnp4,seismo,ctvax}!ut-sally!jsqfalk@uiucuxc.UUCP (02/04/85)
{}
We've had very good luck with DEC engineers on both our VMS and Unix Vaxen.
Their response time is good, they are interested in solving our problem,
they are not hesitant about swapping out possibly "good" cards, power
supplies, etc., to find the problem and they train their new engineers with
the "old pros". I'm afraid I'm getting spoiled because we've had some of
these guys for several years and I'm afraid that they'll leave soon and
we'll get somebody that doesn't know anything, but so far so good.
-Connie
p.s. the vaxen don't fail a whole lot, anyway. Usually, the failures come
as "rashes"- several all at once, followed by a long quiescent period.ron@brl-tgr.ARPA (Ron Natalie <ron>) (02/05/85)
> I really have no complaints about our local DEC field service (NYC). > When I came here about 5 years ago, we had 3rd party maintenance -- now > THAT was a disaster. A few things I've learned about dealing with Field > Service: > > Tell them what they need to know -- don't hide screw-ups. We > once snagged a Unibus cable trying to fix something ourselves. I told > them what happened, and they fixed it. If you have a reasonable branch > manager (we do) s/he will realize that bailing you out is cheaper than > having you hide the problem and waste his techs' time trying to find it. > > Watch, observe, be aware of what's going on, make suggestions if > you REALLY think you know something they don't, but don't get in the way > (I had a LOT of trouble learning this one). > > If you have a problem with a particular technician, request that > that particular person not be assigned to your site. Let them break > someone else's machine. Let's face it -- I've seen some techs who I > wouldn't trust to sharpen my pencils. > > When the techs finally get your machine running again, let them know > you appreciate it. Scratch them behind the ears or give them a nice warm > bowl of milk. > -- Well, DEC tends to be different in each office. The people in DC tell me they have no problems with DEC. We have routinely miserable problems. It took them an average of one month to install each of four 780's we have. Part of this is attributable to poor qualitiy control from the factory, but a large share is the first line support people being incompetent. We don't trust them anymore. Both here and in Denver DEC did not listen to us, and did some very questionable things in their service procedures that caused extended down time. Again, the most irritating strategy is to make the first line support people the lowest trained person on the team. After he screws up for three days, then they provide for escalation with other people who know something. Sorry. DEC is well aware of what their problem is, we've told them at a meeting they called after they did not get the 1.5 million dollar BRL maintenance contract. -Ron
david@ukma.UUCP (David Herron, NPR Lover) (02/07/85)
In article <813@ut-sally.UUCP> jsq@ut-sally.UUCP (John Quarterman) writes: >They've gotten better, at least in remote diagnosis. >The local reps have mostly gotten over their UNIX-phobia, as well. We're even teaching ours what UNIX is. (Though rogue has something to do with that...:-). He's even a good repairman at that.
phil@amdcad.UUCP (Phil Ngai) (02/07/85)
> p.s. the vaxen don't fail a whole lot, anyway. Usually, the failures come > as "rashes"- several all at once, followed by a long quiescent period. Speaking of failures, has anyone noticed a correlation between power failures and increased breakdowns shortly afterwards? We had the power go off on a Wed and an RP07 head crash the following Friday. DEC fixed it on the morning of the first working day after we called it in. They said it required a new HDA ($21,000) but didn't think the power failure had anything to do with it. Since it doesn't cost them anything to suggest we get cleaner power, I guess it really isn't a factor. But I still wonder. Anyway, I'm satisfied with DEC field service so far. -- This is my opinion, I guess. Phil Ngai (408) 749-5720 UUCP: {ucbvax,decwrl,ihnp4,allegra}!amdcad!phil ARPA: amdcad!phil@decwrl.ARPA
tihor@acf4.UUCP (Stephen Tihor) (02/08/85)
Is our DEC service decent? Basically. We usually have to train our guys by hand on use of BOTH VMS and Unix except in the most simple tools, but they usually learn. They have dropped anything into a spinning disk drive in over two years. Have we had problems after power hits? Sure. Each time ConEd graces us with a brieef power hit or rollercoaster surge out FPS 164 tosses its cookies, frying boards left and right. Then one of the fixed disks get a bad block. Then some systems start crashing. Generally, over the course of a week thereafter the overstresseD boards will start to fail. We lost one RP07 HDA that way, several UDA50's and a DEUNA. The problem is much agrivated by any existing enviornmental stress.