|
I had a meeting with Brian Adams, Terry Card & Frank Briggs, re
merging the Micro Vax element of Office Systems & Systems before
I caught the pox. Terry spoke to his group & later with me. The
consensus was that it would be a good move amongst the Office Systems
engineers I spoke to.
Terry did point out several features of Micro Vaxes that perhaps
we are unaware of, for example most diagnosis is phone related
& of engineer queries regarding configuration problems.
Another major factor to be considered is the volume of new products
coming out in the Uvax area compared with new Systems group machines.
Also the power of some of the newer U's is up to 7 mips, using the
PELE 4000 for example. The product overlap therefore is quite
significant. Also in the Office group there tends to be one
specialist on each product by default due to the sheer number of
products on the market. This creates problems when an engineer takes
leave or training. If a merge took place a greater number of
specialists could become available via cross-training.
A possible merge might also allow us to create specialist
groups, ie cluster desk, bugcheck desk, Workstation desk etc.
Another positive factor of merging would be greater customer
satisfation & standardized analysis, also creating greater
product scope & career prospects for engineers in both groups.
I have had some positive feedback already in this conference, but
I would like to obtain any further comments, suggestions feedback
etc which may help in developing a joint Systems group.
Feel free to mail me or even speak to me if you want to, offline.
I have also entered this as topic 19.8 in the Systems notes file.
Cheers Richard.
|
|
A reply to Richards mail
See my ! comments
Ken.
From: KERNEL::KERNEL::MOUNTFORD "06-Jun-1990 1015" 6-JUN-1990 10:44:10.97
To: @SYSTEMS.DIS
CC: MOUNTFORD
Subj: Merger.
Hi guys,
There seems to be some confusion about the merge of Office & Systems
groups & Regionalisation. Let me spell out my own viewpoint.
Firstly it was on the cards that our two groups would at some stage
merge after Ken Robb had completed his report into the RDC ability
on Micros.
!I have had full agreement on my proposal for RDC on microvaxes from
!marketing who are in the process of mailing the field and customers.
!
!The proposal was to make RDC available as a tool should there be a benefit
!in connecting.
!
!This service should be available on the larger systems (3500, 3600 etc)
!where there is already a decnet connection to a system currently on RDC.
Marketing are letting customers & sales know of the
go ahead of RDC on micros & to this end we need to get ready for
an influx of extra calls.
!There should be no difference in the number of calls as the customers
!already log all their calls with office systems.
Office Systems have little experience of dialling into micros &
!They have had some training from the seminars given by Norm P and John T
!and have already made a number of connections and there is plent of
!help avialable from our group.
of handling Bugchecks on them.
!They should not have to. My proposal was that all bugchecks went to the
!bugcheck desk regardless of what size VAX they were on.
Systems on the other hand have the experience in both areas but not on the
Micros hardware itself.
!We have difficulty in getting the skills to cover our own product range
!without micros hardware as well and I am sure Micros engineers are in exactly
!the same position. We do however have the skills for bugchecks and anyone
!wishing to progress their career in that direction should do so from within
!that desk.
It would be nice to combine resources at the same time as any Regional
CSC plan if at all possible, but it may not be practical from a
business point of view. We therefore need to liase to a certain
extent as to what the Regional group reps meetings come up with
as far as a CSC model might look like,
!I think we need to liase a LOT with both the regional group reps plus ALL of
!the people affected ie MEMBERS of the systems group before going ahead and
!making decisions like the ones below. Isn't this better done as part of
!the whole regional discussions and changes with involvement of the regional
!group reps.
but in the meantime we need
to cross-train & get up to speed diagnosing micros & conversely
train Office engineers on Systems products.
!One of the main problems in the Office group is the vast range of products
!that they have to work on. Mass cross training will only make that problem
!worse, not help to give the customer a better quality service.
!I would suggest that the first thing that is needed is for ALL devices
!be handled by the device group.
!
!In our recent meetings we have talked about the best way for the customer
!of resolving their problem. The consensus has always been that we should get
!the call to the best specialist as quickly as possible. Office systems
!engineers are the best specialist in that area. Don't dilute it.
!There are already a high volume of calls in the microvax area.
!We have enough problems getting sufficient training and experience on the
!range of products in each group already.
!I suggest the microvax engineers from the Office system group merge with
!the system group but not the whole of Office systems.
Andy Hopkins is setting up some swaps with the bugcheck desk &
!All bugchecks should be dealt with by the bugcheck desk. Get the customers
!problem to the best skill.
hopefully Systems can reciprocate helping Office out. To this end we
need to get some cross-training sorted out.
!I don't understand this bit. Cross training will dilute skills and reduce
!the level of service to the customer at a time when we should be aiming to
!improve it.
I have obtained
a list of Office products from Mike Ayling & volumes of calls per
product. I have also suggested courses for Office engineers. Most
of the training is IVIS based so I would now like volunteers please.
!Sounds like decisions have already been made. What about OE and some
!group discussion first.
The suggested products for Systems engineers are Microvax 2, & the
3000 series together with Q-bus concepts. For Office engineers
BI-concepts, BI adapters & the 8200/8300 systems for starters.
!As above
Cheers Richard.
!I believe there is real benefit to the customer as well as individuals in
!each group in the systems group merging with VMS, ULTRIX and the micros
!engineers from office products and that it should go ahead in a coordinated
!way. The merger will give individuals the opportunity to move from one
!specialist area to another should they so wish and there is a slot available.
!I support a merger with the VMS group but that does not mean we all become
!cross trained on software products and all VMS group become cross
!trained on hardware products (Unless an individual wishes to change focus).
!It will create a better atmosphere for cooperation between specialists which
!in turn will give the customer a higher level of service without bouncing
!calls from one group to another.
!With Country Support long gone and Product and Technology having less and
!less hands on CSG is the only place where it is possible to specialse to the
!degree we do. Such specialisation is necessary to support the complex
!problems we see today on our customers systems today.
!End of my comments, Ken.
|
|
A reply to Ken's comments.
-------------------------
!I have had full agreement on my proposal for RDC on microvaxes from
!marketing who are in the process of mailing the field and customers.
!
!The proposal was to make RDC available as a tool should there be a benefit
!in connecting.
!
!This service should be available on the larger systems (3500, 3600 etc)
!where there is already a decnet connection to a system currently on RDC.
Presently most Microvaxes are diagnosed by phone & mostly as hardware faults.
By comparison Systems are nearly all diagnosed via dialling in & very few
are hardware faults these days, many are software problems fixed via patches.
Hence the quality of service seen by the same customer on different
machines is different & needs standardising.
!There should be no difference in the number of calls as the customers
!already log all their calls with office systems.
I would suspect that not all calls are logged by the customer at the present
time. From my own experience of dialling into micros I have found either no
dump found or none set up indicating perhaps that bugchecks on micros are not
logged normally.Also we have no idea of how many LAVC'Ed micros crash & are
re-booted straightaway.
!They have had some training from the seminars given by Norm P and John T
!and have already made a number of connections and there is plenty of
!help available from our group.
You forgot me Ken, I was involved with DSDN in a small way, but my original
comment stands that micros have LITTLE experience of dialling into systems.
:)-
!They should not have to. My proposal was that all bugchecks went to the
!bugcheck desk regardless of what size VAX they were on.
Why shouldn;t they? As you say later we already have a large workload of our
own. Contradictions?
!We have difficulty in covering our own product range without micros hardware
!as well
Q.E.D.!
!I think we need to liase a LOT with both the regional group reps plus ALL of
!the people affected ie MEMBERS of the systems group before going ahead and
!making decisions like the ones below. Isn't this better done as part of
!the whole regional discussions and changes with involvement of the regional
!group reps.
I outlined this plan on the 22nd May in note 19.4 in this conference. There
was vocal support from 3 members of the Systems group on this subject. I
invited Brian Adams & Terry Card along to the meeting with Frank on the
23rd May & duly informed both Office & Systems groups of the contents of
that meeting. I also discussed the proposals with the 4 members of the
Office group out of a possible 7 who would be affected who commented
positively. I cannot pressure people to comment if they don't have the
inclination to reply. I fully agree that discussion is paramount hence
my later mail message yesterday suggesting reps attend our next meeting.
!One of the main problems in the Office group is the vast range of products
!that they have to work on. Mass cross training will only make that problem
!worse, not help to give the customer a better quality service.
!I would suggest that the first thing that is needed is for ALL devices
!be handled by the device group.
Exactly, the product range is large & there are 7 engineers supporting them.
Nobody mentioned "MASS CROSS TRAINING" I spoke about the specific products
covered by RDC in keeping with volumes of calls, the training is only a
day or 2 of IVIS & it would give us the background to the products. There
are no level 2 courses anyway.
Why should training make the problem of "a vast range of products" worse.
Sorry I don't understand your comment?
Yes that was also suggested regarding moving Office devices to the Devices
group, I fully support that move.
Also I feel strongly, that customers are bound to benefit from greater
numbers of trained engineers. As Terry pointed out when one of the office
engineer is out there is no expertise on certain products.
!In our recent meetings we have talked about the best way for the customer
!of resolving their problem. The consensus has always been that we should get
!the call to the best specialist as quickly as possible. Office systems
!engineers are the best specialist in that area. Don't dilute it.
!There are already a high volume of calls in the microvax area.
!We have enough problems getting sufficient training and experience on the
!range of products in each group already.
!I suggest the microvax engineers from the Office system group merge with
!the system group but not the whole of Office systems.
I agree that only Micros merge, that was proposed. I would also ask you to
consider the effect of not having anybody trained on the products when on
nights. The product range as I mentioned greatly overlaps now, with
the new multi-processors, the main difference from any other Vax is the bus
system.
We already deal with Unibus/BI/XMI/MASSBUS/Qbus on 11780's & Microvaxes
on Polarstar front ends. We are also expected to take tele-support calls
on any flavour of PDP.
!All bugchecks should be dealt with by the bugcheck desk. Get the customers
!problem to the best skill.
I agree but why specifically Systems engineers, why can't micros engineers
become trained to handle them, why shouldn't their career paths be expanded?
!I don't understand this bit. Cross training will dilute skills and reduce
!the level of service to the customer at a time when we should be aiming to
!improve it.
I totally disagree. Nobody has been consulted on which products they might
wish to support. Micros are turning out far more products than Systems
products & are barely able to keep pace. I foresee the need at some stage
to drop labels completely. Take the new 9000 Vax totally different in
many ways but people are still trained on it. Would people seriously
object to being trained on a new product in the Systems group if it
was to adopt the Qbus theory. Polarstar for front-end for example?
I have obtained
a list of Office products from Mike Ayling & volumes of calls per
product. I have also suggested courses for Office engineers. Most
of the training is IVIS based so I would now like volunteers please.
!Sounds like decisions have already been made. What about OE and some
!group discussion first.
Re my earlier comments, the discussion is open to all & has been sitting
in this conference for 3 weeks. No decisions have been made other than
suggested IVIS training for Systems & office engineers.
!I believe there is real benefit to the customer as well as individuals in
!each group in the systems group merging with VMS, ULTRIX and the micros
!engineers from office products and that it should go ahead in a coordinated
!way. The merger will give individuals the opportunity to move from one
!specialist area to another should they so wish and there is a slot available.
!I support a merger with the VMS group but that does not mean we all become
!cross trained on software products and all VMS group become cross
!trained on hardware products (Unless an individual wishes to change focus).
!It will create a better atmosphere for Cooperation between specialists which
!in turn will give the customer a higher level of service without bouncing
!calls from one group to another.
!With Country Support long gone and Product and Technology having less and
!less hands on CSG is the only place where it is possible to specialise to the
!degree we do. Such specialisation is necessary to support the complex
!problems we see today on our customers systems today.
!End of my comments, Ken.
I fully support your last comments & feel that all these proposals will come
together. My only interest outlined so far is dealing with Office &
Systems groups. I have attempted to communicate at all times the current
situation & would certainly wish discussion to continue before any
formal decisions on how we merge is adopted. All I have done is propose
some small amount of cross-training as a prelude to merger & also help
manpower problems.
Finally it is fine for engineers to have career goals but don't forget the
business aspects. Quote from the March edition of MMGT MEMO " Technology has
advanced so rapidly that the demand is now for desktop systems with full
application & network support".
Richard.
|
|
This note was from Clive Brooker.
---------------------------------
Richard,
Steady now, relax, take deep breaths and count to ten......
there, feeling better? Good.
Right, let's put all our personal aspirations and career goals
to one side and approach this issue on a logical basis. This proposal
( whatever it is and where-ever it originated ) has major implications
upon the entire Systems group operation as well as upon the lives and
future careers of its' members. As such, and in accordance with the
spirit of OE, it needs to be presented to a full Systems group meeting,
discussed in detail and an exchange of ideas and a consensus of opinion
sought. At this point any agreement achieved should have the support
of the people involved and implementation, with management approval,
becomes a harmonious group driven process.
At this moment you do not have that support.
So, if you have a personal proposal which you feel will
increase the level of service we supply to our Customers please feel
free to seek the opinions of your peers in preparing your case, but
don't assume tacit agreement from those of us who decline to respond.
I look forward in eager anticipation to your presentation.
|
|
DIGITAL EQUIPMENT CORPORATION
FEASIBILITY STUDY FOR
CONNECTING RDC TO MICROVAXES
UK CUSTOMER SUPPORT CENTRE BASINGSTOKE
DATE: JULY 1989
BY: Ken Robb
UK CSG
CONTENTS
1.0 Summary
2.0 Background
3.0 Objectives
3.1 Non Goals
4.0 Sytems and options
4.1 Software
5.0 Data collection
5.1 Local practices
5.2 Previous calls
5.3 Local survey
5.4 Feedback from Valbonne
5.5 Feedback from Atlanta
5.6 Work methods
6.0 Resourses
7.0 Tools
8.0 Customer feedback
9.0 Conclusions
10.0 Recommendations
10.1 Skills
10.2 Customer requirements
10.3 Future
1.0 SUMMARY
This report looks at the implications of remote diagnosis on microvaxes
either via SET HOST from a node already on RDC or connecting a modem and MDS01
directly to the microvax.
2.0 BACKGROUND
Currently the UK CSC do not RD (Remotely Diagnose) microvaxes by connecting
to the system. All microvax calls are made to the CSC (Customer Support Centre
) and routed to the appropriate group ie devices, office, comms. The call is
then dealt with by the engineer speaking to the customer. A customer with
microvax systems may also have 11730, 11750, 11780 systems at approximately 1/3
to 1/2 processing power of the microvax. Both "large" systems and the more
powerful microvax can have the same disks on yet only the less powerful systems
have RDC. This has caused a number of customers to comment on the apparent
different level of service. It is also possibly not the most efficient method
for DEC to maintain microvax systems. Traditionally DEC has not remotely
diagnosed microvaxes because they were smaller less powerful than microvaxes
are today. Microvaxes also had small disks where as todays microvaxes can have
the same disks as any system on RDC. It is assumed that the reader is already
aware of the way CSG use skills and resources to diagnose customers systems
that already have RDC connected.
3.0 OBJECTIVES
The objective of this investigation was to determine as far as possible
the costs and benefits of diagnosing all problems microvax systems by
connecting to the system via RDC. The possibilities are as follows.
o Install MDS01 and modem directly to microvax system console and dial
in directly
o Set host to microvax after dialling into an existing Vax system that
already has an MDS01 and modem.
Investigate the skills required to benefit from connecting to a system
and comparing with current skills used for phone diagnosing of problems.
See if any benefit could be gained by using the software tools
currently used on the systems connected to RDC.
As this investigation is taking place at the same time as the SDD
(symptom directed diagnosis) pilot is running some investigation was also done
to find out what effect SDD would have on the decision.
3.1 NON GOALS
There was no intention to carry out any pilot at this stage.
No plans to measure manpower requirements.
No plans to measure hardware requirements.
4.0 SYSTEMS AND OPTIONS
o Microvax II -10 users with RA60 RA81 Disks
o Microvax 3300 \ 40 plus users with
o Microvax 3400 / RF Disk
o Microvax 3500 \ 40 plus users with
o Microvax 3600 / RA82 RA70 Disks TU81 Tape
o RA series disks
o RD series disks
o RF series disks
o TK50 tape
o Magtape
o Comms options
4.1 SOFTWARE
o Current versions of VMS
5.0 DATA COLLECTION
Various methods of data collection were used. They are as follows.
o Talking to engineers in each of the groups involved and getting their
feedback. ( Within Viables)
o Looking at problem statements and diagnosis on a months calls.
o Surveying engineers taking calls on microvax systems.
o Talking to CSC engineers and getting call information from RDC in
Valbonne.
o Talking to CSC engineers, managers and getting call information
from Atlanta USCSC.
o Attending unit meeting where work method and call distribution was
discussed.
5.1 LOCAL PRACTICES
During discussions with individuals there was a feeling that value could
be added on system, comms, and disk calls .A common method of diagnosing a
problem is to have the customer describe symptoms/errorlog entries under
direction of the CSG engineer. This is both very time consuming and prone to
error. On system calls for machine checks it would be beneficial to use machine
check analysers. Bugcheck calls could be dealt with by the bugcheck desk down
line loading patches where the problem was found to be a known problem fixed by
a patch.
On RA series disk calls it is currently not possible to use the very
valuable tools such as DSAERR and FSTERR. These tools can allow the CSG
specialist engineer to fully diagnose disk problems saving time and parts on
site.
With network problems there is real benefit in connecting to a system
and using the tools available within NCP directly to solve problems. This can
very often save a site visit.
It was felt that no or little value could be added on tape calls, the
majority of which are TK50 stuck in drive problems.
5.2 PREVIOUS CALLS
To find the number of calls that I believed could benefit from RDC
being connected to the system I took a previous months microvax calls from
CHAMP PC and attempted to split them into the following groups.
o Fully diagnosed. No value would have been added by connecting.
o Value could have been added with RDC.
o Console required. MDS01 and modem would have been necessary for
connection.
The calls were further split into call type as follows.
M3000 family
------------
Fully Value could Console
Diagnosed be added required
____________________________________________________________________________
Disk 14 15 1
Tape 23 0 0
Comms 15 0 0
CPU 6 11 7
Software 2 1 0
Bugcheck 0 5 0
Terminal 9 0 0
Line printer 15 0 0
----------------------------------------------------------------------------
TOTAL 84 (73%) 32 (27%) 8 (6%)
____________________________________________________________________________
Microvax II, 2000
-----------------
Fully Value could Console
Diagnosed be added required
____________________________________________________________________________
Disk 10 21 1
Tape 75 0 0
Comms 31 7 0
CPU 11 22 17
Software 0 2 0
Bugcheck 0 0 0
Terminal 31 0 0
Line printer 29 0 0
----------------------------------------------------------------------------
TOTAL 187 (78%) 59 (22%) 17 (7%)
____________________________________________________________________________
5.3 LOCAL SURVEY
To confirm the results obtained so far I carried out a survey by asking
engineers in each group to fill in details of each call as they did the call.
In addition to the previous questions I asked for the additional time required
to diagnose the call had RDC been connected. See appendix A for survey form.
All Microvax
------------
Fully Value could Additional Console
Diagnosed be added minutes/call required
____________________________________________________________________________
Comms 14 13 9.6 0
Office 5 12 10.6 6
Devices 13 18 9.1 5
----------------------------------------------------------------------------
TOTAL 32 (42%) 43 (58%) 11 (%)
____________________________________________________________________________
The percentage of calls where value could be added by was estimated by the
engineers doing the calls to be 58%. This was very higher than my first pass
estimate which was made by looking at trouble statements and recommendations
from closed calls.
5.4 FEEDBACK FROM VALBONNE
To establish how effective RDC on microvaxes was in practice I spoke to the
RDC engineers in Valbonne where they are currently connecting to microvaxes.
The feeling was that RDC was very effective but no evaluation was done before
starting and no measurement to check its effectiveness. I got the following
feedback from RDC in Valbonne.
1.Of the systems on your database what percentage have an MDS01 and what
percentage do you set host to?
100% of the UVAX2 have MDS01
2.What type of problem are you remotely diagnosing on microvaxes?
The kinds of calls are : 1] Disks errors
2] Bugchecks Analysis
3] Vms problems
4] No boot
3.How many calls per month do you have on microvaxes?
******************************* DECEMBER 1988 ******************************
CPU CM CA TA RD VE AUS RNV EM PM CR RND DE RNT Total
MVAX2 3 0 5 0 0 5 4 0 0 0 0 1 2 20
M3000 3 0 3 3 0 0 0 0 0 0 0 0 0 9
Totals 6 0 8 3 0 5 4 0 0 0 0 1 2 29
*******************************************************************************
******************************* JANUARY 1989 *****************************
CPU CM CA TA VE RNT AUS EM CR RD RND DE PM RNV Total
MVAX2 2 2 6 2 7 2 0 0 0 4 0 0 1 26
M3000 2 3 4 2 0 0 0 0 6 0 0 0 0 17
Totals 4 5 10 4 7 2 0 0 6 4 0 0 1 43
*******************************************************************************
4.How many of those calls do you connect to the system?
It depends of the problem.
5.How many of the microvaxes are 3000 series?
We have 241 Microvaxes II (now) and 176 Microvaxes 3000
6.Did you do any evaluation work before taking microvaxes onto RDC
or are they just treated the same as any other system when deciding
if a system should go onto RDC?
No.
For us there is no difference between a 88xx and a Microvax.
(From RD connection point of view).
7.What are the advantages and disadvantages you have found?
The disadvantage is that every Uvax MUST have an MDS01 and a MODEM
(Except may be in LAVC where they can shared the same modem but
they need to have their own MDS01 , if not customer would have to
manipulate to many things for a RD connection.)
The advantage is that you will have calls on new product (Uvaxes,LAVC).
Second point is,if a customer calls us for a Uvax and if we have the
system in our database we can validate the call (even if we do not
connect) ,and, deliver to him the best service we can.
If the system is unknown,you cannot rely on the 'guy' you have on phone.
Anyway for us (RDCs), due to the fact that you will never see the system
where you will connect , there is no different if it is a 8800 or a UVAX
(Except may be in the console command).
5.5 FEEDBACK FROM ATLANTA
I have spoken to a number of the RDC engineers and RDC, USCSC managers on
effectiveness of RDC and how SDD was affecting the decision to have RDC on
microvaxes. The RDC manager believed that an evaluation had been carried out
before connecting RDC to microvaxes however I was never able to find anyone who
would admit to having done it.The feeling again was that RDC was very
effective. A pilot run lasting 8 months was carried out where the outcome of
which was a decision to go all out for connecting RD to microvaxes. I got
comments like "We can't afford not to have RDC" and "With RDC and SDD we have a
winning combination that the competition find hard to beat". RDC is also used
to down line load patches where analysing a bugcheck has identified a problem
as being fixed by a patch.
In an effort to get hard facts I asked for and got the following report.
Author: William R. Thompson@alf
Business Planning Group
Date: 13-Jul-1989
Posted-date: 13-Jul-1989
This report is to give assistance in determining whether RD should be a viable
support tool for MicroVAXs in Europe. Some data has been interpolated to give
an overall average to assist in giving some business sanity to the reporting.
The first part of the report will respond to the questions stated in one of your
earlier memos, the second part will be some actual RD call volume information.
1. Questions concerning RD support on MicroVAXs:
o Of the systems on your RDC database what percentage have an MDS01 and
what percentage do you set host to?
Approximately 50% have MDS01s, 50% have set host activity.
o What percentage of the MicroVAXs on your database are 3000 series?
60% of the MicroVAXs on the database, and registered are 3000 series.
Other RDable systems include the MVAX2000. Most of the 3000 series are,
however, MicroVAX/VAXserver 3500/3600/3602 due to no availability for
VAXsimPLUS yet to fully detect errors on DSSI technology-based MicroVAXs.
o What are the monthly number of calls in each of the systems types? e.g.
MicroVAX 2, 3500, 3600?
Total calls are exceeding 1000 per quarter now on MicroVAXs; MicroVAX
3300/3400 is still so new that only IVPs (Initial Verification Process)
are being performed on these- There is no real breakdown of particulars
though.
o What is the average time on each call where you connect via RDC?
It depends upon which kind of RD call-that is, whether the call is only a
simple Initial Verification Process (IVP), or if a crash dump has to be
performed, or if there is an extensive error log that must be run.
Usually an IVP is approximately 20 minutes, error logs and crash dumps
are anywhere from 50 minutes to 3 possibly even 4 hours.
o What is the average time on each call where you do not have RDC?
30 minutes average-although there is NO IVP without MDS01.
o Of the systems on RDC, what percentage do you connect to for a customer
call?
Connection is performed for 99% of the customers with systems on RDC.
The other 1% there is no connection due to a number of reasons including
system completely down, problems with the MDS01 box itself, or the MDS01
has been installed, but not the software VAXsimPLUS and SPEAR.
o Where the system is on the RDC database- What percentage of calls can you
close with "no engineer required"?
60% on the average of calls are closed with "no engineer required".
o Where the system is not on the RDC database-what percentage of calls can
you close with "no engineer required"?
Normally these customers would not call into the Customer Support Centre
for RD support-but they may possibly register their system, have RDable
hardware and software installed, then call for RD sessions like as in the
question above.
o Where the system is on the database- What percentage of calls can you
identify the failing FRU?
90% on the average failing FRU's have been called out correctly with
utilisation of RD.
o Where the system is not on the RDC database- What percentage of calls can
you identify the failing FRU(same systems as in the question above)?
This data is not readily available since these calls would not go to RD
for a dial-in session. Normally, with customers not having systems that
are RDable, CSC engineers and specialists do their best to call out the
correct failing FRU. However, the CSC engineers and specialists usually
do not receive any feedback from the field as to the accurateness of the
FRU callout.
o What is the breakdown of call type e.g. disk, communications, tape,
systems, etc.?
10% on the average are systems, 20% are tapes and tape drives, 20% are
disks, and 18% are memory. The balance are usually non-hardware related.
2. Actual Call Volume Data
Actual call volume data represented is for one quarter:
SYSTEM NEW TOTAL PROBS/ TOTAL PCT
PROBS WORK UNITS REG TIME(MINUTES) (MINUTES)
MicroVAX 2(630Q) 228 307 1.3 9,593 31.25
MVAX 3500/3600(650Q) 378 456 1.2 10,979 24.08
MVAX 3300/3400(640Q) 12 14 1.2 430 30.71
Description of the terms:
o IVP (Initial Verification Process) - This is a merely a 'dial-into' the
customer's system via remote diagnosis tools (VAXsimPLUS and remote console
MDS01) to verify installation of system and remote diagnosis tools and that
all is working.
o New Problems - A new problem is generated per each new unique problem.
o Total Work Units - The total number of calls per each unique problem.
o PCT (Problem Cycle Time) - The time (in minutes) per each call.
5.6 WORK METHODS
By speaking to the engineers in the Office Products Group and attending
a unit meeting I discovered that most have a very wide range of skills but do
not go into problems in any depth. No attempt is made to analyse machine checks
or bugchecks. For RD disk calls a typical diagnosis would be to isolate the
problem to a drive. This is in contrast to the rest of CSG where the skill
range of each engineers skill is narrower but goes into more depth.
On the following page is a list of products that a member of the office group
may be expected to work on. While not every member of the group works on all
products the spread of skills usually involves tapes, disks, systems hardware
and bugchecks, plus various QBUS options.
Products handled by Office Products Group
________________________________________________________________________________
MVAX I
MVAX II
MVAX III
MVAX 2000
MVAX 3400
MVAX 3300
MVAX 3600/3602
MIRA MVAX II
VR260 VS II PMAX VSV21
VR290 VS II-GPX PVAX VSV11
VR262 VS I LYNX
VR100 VS 2000 FIREFOX XWEOX XPS-710
VR292 VS 100
VR160 VS 3200 CALMA
VR150 VS 3500
RZ22/23/55
RX01/02
RF30/70
RX33/50
RD
RC25
RV
RA70
TK25
TK50/70
CIPHER CT540
Barclays MK I, II, III, IV, V
Barclays GPW
MICRO 11/23 1103
11/73 1123
11/83 1123+
11/53
MIRA 11/73 MNC11
VT103
HARTLEY 103
TPL
INDUSTRIAL PRODUCTS
CSS PRODUCTS
NON DEC
________________________________________________________________________________
6.0 RESOURCES
Hardware.
Currently RDC is run from an 11780 node FIXER in the KERNEL cluster. The call
logging / connection software is RSDS. With the current load on the system the
response is not fast.
Manpower.
Additional diagnosis within CSG would require additional manpower.
This would require futher checks after a pilot run.
7.0 TOOLS
A large number of tools are available for use by RDC engineers which are
either not available for use by field engineers or the field engineers do not
get the practice in using the tools to obtain full benefit from them.
The main tool used by microvax field engineers is MDM ( Micro Diagnostic
Monitor ). This requires the system to be shut down and booting a stand alone
diagnostic pack which can take from a few minutes up to 60 minutes just to boot
depending on whether menu mode or cmd mode is used. If the problem is
an intermittent one then the chances of finding the cause with diagnostics is
very slim. Only the support / senior microvax field engineers understand how to
run and use errorlogs yet this is where the information required to identify
the failure is likely to be.
DIAGNOSIS TOOLS USED AT VIABLES
-------------------------------
A. Tools We Use that could be of use on microvaxes
--------------------------------------------------
1. Local Tools
--------------
FUBAR Convert 1178X FUBAR to SBI address
MCHECK_ANALYSER Routine to analyse machine checks
SEL Errorlog Analyser
DUE Dumps Errors in Crash Dump
POINTER Points to Source of Desired Information
BUGS Exposes known problems in System Crashes
STAKS Retrieves Stacks from all RSDS Crashes
REGS Retrieves Registers from all RSDS Crashes
HEXTIME Converts system time to ascii
ZAP Errorlog Threshold Detector
SCRIPTS Dump/PM/EM/CM scripts. Online Scripts
DT Viables Diagnosis Toolbox
2. Support Tools
----------------
RSUM Automatic RHM output of SPEAR/ERF/ZAP
FAST_SNAP Fast Snapshot Analyser
SEDSWSPARTS SEDSWS Part Number Finder
3. Digital Tools
----------------
SDA System Dump Analyser
FSTERR Tape/Disk Errorlog analyser
DSAERR Disk Errorlog analyser
BLOCK Allows manual convertion of Disk LBN's
SPEAR AI Errorlog Interpreter
CDX Crash dump diagnostician
CANASTA Crash Analysis and Trouble Shooting Assistant
VAXSIM VAX Monitor
STARS Information Database
NOTES Sources of Information
ERF Error Formatter for Errorlog
NETSYS Netsys Programs
VAXPAX Valbonne Database
8.0 CUSTOMER FEEDBACK
From time to time we hear comments from customers on the apparent different
level of service between microvax and midrange systems.
The last customer presentation I did I was asked why we did not RDC
microvaxes and other customers find ways around the problem. While on the
bugcheck desk I have had a customer log a call on an 11750 only to be told "the
bugcheck is from a microvax but you don't connect to them do you". Also calls
come from exceptions or from local offices. In each of the bugchecks I have
dealt with in this way the problem has been fixed with patches or a software
call has been opened. No engineer was required to visit site.
9.0 CONCLUSIONS
If RDC is connected to a microvax we have the tools and capability within CSG
to give a first class diagnosis at considerable saving to the field.
There have been enough comments from customers to indicate that they want RDC
on their systems and that they would see it as a real improvement in service.
From the results obtained in Atlanta and from local surveys there is enough
evidence to indicate that benefits could be gained by dialling into microvaxes
from RDC however there are various options that would give different levels of
cost and benefit.
Analysing a bugcheck on a microvax is identical to analysing a bugcheck on any
other Vax and the patch required is the same ( for V5 VMS and greater ).
Currently on an RDC system a patch can be down line loaded where as on a
microvax system a hardware engineer is likely to be sent to site where the
processor module will probably be replaced.
Two of the most important figures from Atlanta are 90% hit rate on fru's and
60% no engineer required.
From experience in Atlanta RDC can be used on approximately 50% of systems
without any additional hardware being installed on site. This would include
sites where there is already a modem and an MDS01 connected to an existing node
in a network or where the microvax is a part of a mixed cluster with the boot
node already on RDC.
The larger the systems the greater benefit from connecting to RDC therefore
3500/3600 systems would benefit more than microvax II systems.
OPTIONS
1. Do not connect RDC to any microvaxes. ( Current situation )
2. Connect all microvax II and 3300/3400, 3500/3600 to RDC supplying a modem
and MDS01 where necessary. ( As in Atlanta )
3. Connect largest systems 3500/3600 ( where most benefit can be gained )
where there is already an RDC connection into the site ( Lowest cost )
9.1 SKILLS
To obtain maximum benefit from connecting microvaxes to RDC a reassessment
should be made in the way skills are currently used. It is not possible for one
engineer to have in depth knowledge in cpus, tapes, disks, bugchecks etc.
9.2 RESOURCES
As microvaxes go on SDD ( Symptom Directed Diagnosis ) they are being added
to the RSDS database. This however has very little overhead. If a large number
of microvaxes were to suddenly go onto RDC without additional/more powerful
hardware there would be an overall impact on the whole of CSG in response time.
10.0 RECOMMENDATIONS
We have enough evidence from our own operation and from Atlanta to start
RDC on microvax 3500/3600 systems ( option 3 ) where the system has a decnet
connection to a system already on RDC. A number of these systems will already
be added to the RDC database as they are added to SDD.
There is a separate project measure the quality of diagnosis and this should
be used to measure the quality of RDC on any microvax systems that go onto RDC.
10.1 SKILLS
To obtain most benefit from RDC on microvaxes calls should be dealt with by
specialists.
Currently comms calls are dealt with by the comms group. I suggest this be
extended to other options to include the following.
All disk calls go to the disk group. This should include RA, RF, and RD disks
All tape calls should go to the tape group.
All bugcheck calls should go to the the bugcheck desk.
This would allow engineers from the office group to increase their skills in a
chosen area by working on the bugcheck desk, devices group or remaining where
they are. Without having to work on such a wide range of products individuals
have the opportunity to increase their knowledge in a chosen area.
A small amount of cross training may be necessary within the devices group to
handle disks and tapes that are currently handled by the office group.
10.2 CUSTOMER REQUIREMENTS
We should require the customer to have a FIELD account and to be running the
error logger as well as having a dumpfile.
The customer should also have a problem free methold of connecting and
setting host to a system (No requirement on Digital to contact a seperate
system manager to dial into the host system).
10.3 FUTURE
The calls should be monitored for a period of 6 to 8 months and compared
with a similar number of systems not on RDC. A decision could then be made
about extending RDC to smaller systems and systems requiring a modem and MDS01.
Appendix A
MICROVAX CALL SURVEY (CHAMP PC)
________________________________________________________________________________
Name _____________________ Group _______________ Date from _______ to _______
________________________________________________________________________________
| OPTION | FULLY | IF RDC HAD BEEN CONNECTED
| | DIAGNOSED |-------------------------------------------------------
| | | VALUE COULD | ADDITIONAL TIME | WAS THE |
| | Y/N | BE ADDED | REQUIRED (HH:MM) | SYSTEM DOWN |
________________________________________________________________________________
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
|