Conference 7.286::digital

>Why is that engineering groups in Digital are not responsible for the costs
>to support the products they create?

While the wording of this question is a bit antagonistic (and jumps to
a possibly unfair conclusion) I agree that there is a problem.

It *is* the responsibility of engineering groups to create products that can
be economically supported.  However, the feedback loops that once allowed
engineering to create easy-to-support products are no longer working.

For example, it is virtually impossible for many engineering groups to
even find out what kind of support load their products are creating.  In
the "old days", engineers had direct contact with their customers.  This was
in the days before Customer Support Centers were invented.  When there was
a usability problem, customers would send SPRs and they *always* landed
on some engineer's desk.

I remember when the SPR form (yellow paper) was a direct message from a
customer - we could even tell how mad they were from their handwriting!
I also remember how angry I was when we stopped accepting handwritten SPRs.
Creeping bureaucracy.

As the company grew, layers of intermediate filters were created
to deflect customers from direct contact with engineering.  We (the
engineers) lost contact with our customers.

Dare I say that the majority of "support problems" are not even known to
the engineers who caused them.  The wall has become so high that it is
all we can do to throw stuff over it - very rarely do we hear the shouts
(or cheers) from the other side.  But don't blame it on the engineers.
We're just victims of the system.

-steve-

>Dare I say that the majority of "support problems" are not even known to
>the engineers who caused them.  The wall has become so high that it is
>all we can do to throw stuff over it - very rarely do we hear the shouts
>(or cheers) from the other side.  But don't blame it on the engineers.
>We're just victims of the system.

This appears to be a classic communication problem. The CSCs know what products
are eating their lunch, which ones are not, and what the most common problems
are with all of our products. If you send me mail telling me what product
you are interested in I will find someone who supports that product and
have them give you a call. My bet is that the CSC can provide as much
information as you can tolerate and would be happy to do so.

joe

And, on the other hand, as far as I know no support contract money ends up in 
engineering, only part of the license revenue (what's left after the corporate
bureaucracy has taken their more or less rightful shares ;-)

Also imagine the problems justifying engineering groups that create "bundled" 
products with no separate licenses. Take, for example, the now dead Bookreader
engineering group; no money from anywhere to build it, no more product
development.

...petri

    I gave my Engineering group a CSCTLS account so they can read problem
    statements to understand current problems, they can also get an idea 
    of problem volume and the like.  
    
    I am fortunate because my product set and the CSSE / Engineering group 
    I work with this very proactive and cares about support issues.  
    
    As far as who funds who......I know NOTHINGG!   
    

    support costs are mostly people costs, so they're shared by all groups
    in Digital.  Engineering pays for the engineers time, Field pays for
    the CSC.  Hardware ECOs depend on how much it'll cost. :-)
    
    Mark

>>While the wording of this question is a bit antagonistic (and jumps to
>>a possibly unfair conclusion) I agree that there is a problem.

    I don't mean to be antagonistic, really.  I remember starting a
documentation project on a product that (through CSSE research) had cost twice
as much $$$$ to support than the revenue it generated.  This was based on the 
average time to solve problems that came to the CSC.  Over time, SPRs and lots
of customer contact brought things into line and the product continues to be
successful.

    Can Digital afford to put products into the market that take years to turn
a profit because of the imbalance between product revenue and support costs?
Or does this become an exercise in 'funny money' management?

thx,
-s

    
>For example, it is virtually impossible for many engineering groups to
>even find out what kind of support load their products are creating.  In


No it Ain't. Hop on a plane and spend one week with us. You don't even
need to say anything, just listen. And don't go to any meetings or
presentations. Spend the entire week listening to folks deliver support
on your product. I guarantee you'll learn more about the issues/problems
than any other way. Oh, by the way, be prepared to check your thin skin
at the door. Customers tend to be brutally honest when their backs are
against the wall.

Neil (on the front lines)
CSC/CXO

    re: .7
    
    I remember an engineer who did just that and wrote up a great trip
    report.  Unfortunately, he was one of the first TFSO victims.
    
    Bob

The CSCs know how much money is spent supporting each of Digital's products.
Why not post that report in this notes conference every week?  Betcha things
would change pretty crisply!

MS

    >Why is that engineering groups in Digital are not responsible for the costs
    >to support the products they create?
    
    There are, as always, several sides to this uniquely Digital coin.
    It certainly is true that these days it is harder for the engineer
    to relate directly to the customer as there are various filters in
    place in efficiency's name.  It is also true that there are informal
    networks, not well understood by all engineering projects, that allow
    more-or-less direct translation of customer needs/problems to a form
    that the engineer can deal with to solve support problems.  Many
    project and CSC engineers deserve a great deal of credit for closing
    that gap where it has been closed.
    
    In addition to that, there are business practices that we've
    endured since the beginning of time (well, for a couple decades
    anyway) that make it harder and harder to do the right thing
    for the customers.  Witness the IPOs (Independend Product Offerings)
    we now need to kit for the top 25 software products on the AXPs
    so that we can sell service licenses.  The Fortran kit looks
    really silly -- about 1/4 inch of data on the CD, at what I would
    expect is fairly substantial kitting expense -- just so we can sell
    a service license?  Truly, there must be a better solution than this
    which would allow us to only kit on the CONDIST!  This is an example
    of a support cost the product engineers and CSC engineers cannot
    control but that eats into Digital's overall profitability.
    
    I would also observe that a support process that works well only
    when an informal communications network works well is a broken
    support process...
    
    What can we do about it?  First of all, continue to use those
    informal processes or seek them out if we haven't already.  Secondly,
    put pressure on our management to make positive changes.  I know
    I have...each of you has an area of expertise that can probably
    help fix this.  The key is to stop complaining about it and to
    start fixing it!
    
    I now jump off of my soap box...
    
    Leslie

    
    I've worked with engineering groups who are GREAT! The X500 folks come
    to mind. They are always receptive to questions and quick with
    enlightening answers. 
    I've TRIED to work with other engineering groups who were too high up
    on their golden clouds for me to waste their time (THEY will remain
    nameless!).  
    
    I think that alot of the problem is one that has been created over the
    years as a 'class structure' issue.  We're going to see how that plays
    out now that we're escalating calls directly to the engineers instead
    of thru the local office. We've already been 'shat upon' by one lovely
    fellow over our role as gopher in gathering additional information on a
    CLD.  HE felt that he shouldn't have to deal directly with the customer
    (oooh..how gross that would be), but that the speciailist should play
    gopher for whatever the engineer needed.  Obviously, that particular
    engineer feels that specialists are a notch or two down on the food
    chain and that our time isn't worth much.  When the specialist told him 
    that it would make sense for the engineer to pull some info directly
    from the customers system HIMSELF, (rather than the spec retrieving it  
    and forwarding it on the the engineer), the spec was asked if he KNEW
    who he was talking to..............ooooooooohhhhhhhhhhhhhh
    That particular engineer, by the way, is from the group least likely to
    win any "product of the year" award, though they could be looking at
    the "most patched product-but at least we got it out the door" trophey!
    That kind of attitude is, unfortunatly, the one that lingers. 
    
    Oh, and 'thanks' to the HUB900 folks too, for actually sending someone out
    with a demo to tell us all about their product and introduce themselves 
    to us BEFORE their product shipped! I'm actually looking FORWARD to 
    working with this group of engineers!
    

>The CSCs know how much money is spent supporting each of Digital's products.
>Why not post that report in this notes conference every week?  Betcha things
>would change pretty crisply!
    
 	You got to be dreaming, right? If these reports actually did exist
    and were acurate and action was taken based on their content, we
    wouldn't be talking about this.
    
    	In my opinion, the CSC's are clueless on what products are "eating
    our lunch". I'm just glad I'm not a UM in the field consumming
    extremely expensive parts on products that are "unmaintainable".
    
    	Lets talk revenue vs. service expense. We deliver the same type and
    level of service on PC's that we do on VAX9000's. When the field
    service engineer drives accross town to replace a SIMM in a PC, I would
    suspect we just blew our profit margin on 10 (maybe even 20) PC's.
    
    	Its not just an engineering problem. It also includes HOW we
    deliver our service and the expense involved. Is that why Digital layed
    off all their service engineers (to reduce the expense) and now that PC
    that needs a new SIMM sits powered off on a customers desk for weeks
    waiting for someone/anyone to come out and fix it!!! If service
    engineers were too "expensive", then maybe we should have engineered
    "customer fixable" equipment!!!
    
    	This kind of stuff never ends!!!
    
    	Mark

    We are a multi million $ business fixing all that breaks after it
    leaves MFG.
    Any product design engineer who wishes to know what failed on a
    particular FRU since FRS can call me on JGODCL::CRONIN or 
    Bas Grootemaat on JGODCL::GROOTEMAAT and we can give you details of 
    the repair activity in Europe.
    We also have introduced a system whereby the field engineer can get
    details of the repair activity on a FRU he returned for repair to us.
    Again this is for Europe..For details contact Philip Barbonis on
    JGODCL::BARBONIS or Bas Grootemaat..
    We log a lot of repair data annually.Design engineering you are very
    welcome to it..
    Kanata logs good data too on their field return repairs..
    
    Tell me about errorlogs.Why do we get so many modules with no error
    printouts attached?If you start at the DEC/VAX 7000/1000 returns we get
    a fair few.By the time you get to sandpiper forget it no errorlog in
    sight.Thats dumping a lot of $$$ every year.
    
    The problem with not getting errorlogs has been with us as long as
    logging exists.Repairland along with many others got design to capture
    the failing info on the actual failing fru.We called it "on board
    EEprom errorlogging" It worked like a dream.It was a real gem for
    accurate,fast no-indecision repair of intermittant modules that failed
    while operating VMS. We sang its praises and asked for it to be
    implemented on the follow-on platform.The hardware was designed in,the
    console team did their job but when it came to having the operating sys
    software implement the vital part of Operating system SDD logging it
    didnt happen.Can anybody tell me why?
    Its the customer that gets the "intermittant" module back because
    it appears to be NPF.For each intermittant module you get two pissed
    off customers..
    Does anybody have an idea what a p&*&** off customer is valued at these
    days?
    When it comes back in again with the same field
    comment we  scrap it. What a waste of money..
     
    
    A previous noter speaks about CSSE.Do you have a list of names? I
    understood CSSE was disbanded last year.
    
    
     JC.

	The problem is deeper than just Engineering asorbing the costs.
	The problem is that the *no one* knows the true cost for supporting
	a product - the costs are pushed out.

	Consider the 'hidden' costs:

		- training people on a new product

		- the cost of removing people from their current team
		  while they are being trained.  Digital essentially
		  loses a person off the phone for x weeks while this 
		  happens

		- the cost of hardware to support a new product

		- and finally the cost to the corporation to support
		  a product with low quality standards.  This involves
		  the whole overhead of problem reporting and management
		  and includes products of high quality but poor documentation
		  that generate customer calls.
                  
		- service pricing that does not reflect the cost to
		  provide remedial support to the customer.
		
	It is my opinion that if Engineering groups were forced to pay
	for the 'real' costs - the product would be too expensive to
	produce and in a 'real' world - probably wouldn't be released in
	the first place.  If Engineering groups were charged for every
	call that the CSC's had to make on behalf of their product, I
	am certain that you would see:

		- installations that work the first time

		- documentation that accurately reflects the software
		  and provides useful, understandable information to 
		  the customers in the way of examples, tutorials, ect

		- products that work (mostly)

		- timely bug-fixes and releases

	My cynical 2�

	Rick Beldin
	DECwindows Support


	

    Charge Engineering?  So much of our software is given away for
    free, partly due to attempts to increase market share, partly due
    to Service's being unable to figure out who is authorized to use
    a product so we've been giving away "skeleton key" PAKs for five
    years.  Engineering doesn't see a dime from Service revenue, even
    though we do a LOT of the diagnostic work (this does vary from
    product to product, I'll admit.)  With license income shrinking
    due to corporate giveaways, such a plan would essentially kill
    the corporation.
    
    What do the outarageous Service fees we charge pay for, anyway?
    
    				Steve

  Re .15 (Steve)

> What do the outrageous Service fees we charge pay for, anyway?

     i) Seven/eight/nine layers of management ?
    ii) Geneva [ "European Headquarters" ] ?
   iii) The non-Engineering portion of the GMA headcount ?
    iv) "Service consultants" ?
     v) The subsidy on the loss-making products ?
    vi) All of the above ?

  Frank

this is probably the second or third time i have ever written here in 7years, 
but this REALLY turns my flame on.

>>Why is that engineering groups in Digital are not responsible for the costs
>>to support the products they create?

- why is it engineering groups don't get $$$ from support contracts when they
do the customer support rather than the csc

- why is it local offices refuse to push support contracts, so we (the
engineering group) end up providing support for free

- why is the the revenues from our product are NOT pumped back into our
product, but rather distributed to other products whose license sales are about 
1% of ours

- why is it that a product with a huge customer base and sales is not the focus
of attention for growth, and thos of us in engineering who DIRECTLY support
customers can't explain the mixed messages they are getting about the product's
future?

now i have to go work on a diagnostic patch for a customer who won't
let me dial up to their system

>    What do the outarageous Service fees we charge pay for, anyway?
>    

	Well, in the 'good ol' days the service fees might have been
	outrageous but consider some of the new offerings:

		- a six-pack of calls for $500 (no time limit)

		- per call of $200

		- *1 year* warranty support (24x7) on some products

	These days, a $300 product will get you in the door for support
	on almost anything.  The service offerings will be changing to
	have levels of support on *anything* DEC sells - I've heard that
	it will be something like:
		- database access only
		- end-user support 
		- system manager support
		- developer support
	Currently if you have support for product 'x' (it could be a 
	$300 product) you have it *all* - from end-user to developer.

	The problem that the CSC's have always had is where to draw the
	line on support.  Does 'normal' remedial support include:

		- dialin and diagnosis of faulty/poorly-designed products
		- delivery of patches for faulty/poorly-designed products
		- design of workarounds for faulty/poorly-designed products	
                - design of example programs to compensate for incomplete
		  and inaccurate documentation

	You tell me.  SPS won't tell us.  And if we try to tell customers
	where the line is, they ask for a manager and get the support anyway.
	This is slowly changing - but it still happens.
		
	I don't know about all groups, but I know that our group has gotten
	stuck with some products that fit all of the bullet items above.  In
	these days of 'multi-vendor' support we have products that run on
	all kinds of platforms - VAX, AXP, PC, HP, Sun, Ibm, Macs, ect...
	and over all kinds of network configurations.   

	Currently, the CSC is stuck buying all the hardware, all the software,
	getting all the training - and in many cases for naught.  The product
	doesn't meet ship volumes and is canceled in a year.  That's the
	*good* scenario.  

	A *bad* scenario is for a product (words from an Engineer "what
	is there to go wrong?") with some serious deficiencies to go out
	the door and generate tons of calls - many of which may lead to CLDs.
	Another *bad* scenario is for a complex product with low volumes to hit
	the streets and for customers to call in for support.  In such cases,
	the volumes don't allow the CSC people to get enough expertise
	to support people using the product.  So the CSC gets frustrated,
	ships the problem on to Eng, who get frustrated that the CSC isn't
	doing their job, ect...  Even worse, is for the CSC to get stuck
	with products with no Engineering staff behind them, and product
	managers who refuse to retire their products in such cases... 

	The solution in that case is to have Engineering *own* the product
	support until it reaches critical mass.  This way they would experience
	the calls from customers first hand and *hopefully* close the
	loop on the problems that generate the most calls.  At some threshold,
	then transition the support to the CSCs.

	So the costs are there - I think that if Digital better understood
	the *costs* associated with support of a product and realized they 
	are an integral part of	the life-cycle of a product, that many of
	the ill-concieved, ill-designed, too-late, not-enough products would
	not see the light of day.  

	And save us all a lot of money, time, and heartburn....

	Rick Beldin
	DECwindows Support

    
    	We need to move to seamless support organizations. For example, for
    Digital products put local service --> CSC --> eng. qual/support --> 
    development engineering under the Digital Engineering umbrella. For 
    multivendor products, put local service --> CSC --> MCS & Sys. Eng. 
    interoperability support under the Multivendor Customer Services
    umbrella. And probably another thread would need to be contained under
    the Digital Consulting umbrella. 
    	Admittedly, it would be a painful, political process to divvy up
    the organizations but in the end we would hopefully have coherent
    support chains with minimal escalation paths and times, meaningful feedback
    systems designed upfront, cut the bureaucratic nonsense and increase
    customer satisfaction. 
    	If we're ever able to understand and contain costs I believe it's
    essential that we view the service, support, qualification and product
    development as one thread, not separate processes each one entrenched in
    a separate bureaucracy with minimal feedback between them for improvement.
    
    - Jim K

    re:  a couple back.
    
    absolutly spot on. How many times have I been in a position late at
    night where a local manager has ok'd support for a customer not
    covered, let alone for the product he's asking for support on. 
    In my experiance it is quite often the customer who screems and shouts 
    the loudest who is trying it on, or the customer has screwed up big
    time and wants digital to dig them out, you know,  the application
    that has taken months to develope , that fell apart today during testing 
    and it's got to be fixed by tomorrow because it goes live. 
    
    Failing that it's the call for some product you never heard of that's
    not DEC, that the local branch has sold support on, that we have a cat
    chance in hell of fixing.  
    
    	Been there , seen it , not doing it tomorrow.
    
    I know that local customer issues dictate that we bend over backwards to 
    sort something out, but is that not normally where we have screwed up
    anyway. Assesing the risk is one thing , but how much damage is done
    when we assess the risk but not the damage that can be done. 
    
     

    What is the feedback loop between the support group and the
    design community now?
    
    fm

    
    Re:
    
>    What is the feedback loop between the support group and the
>    design community now?

    For all intents and purposes there isn't one.
    
    Dave

    re: .18
    
    >	The solution in that case is to have Engineering *own* the product
    >	support until it reaches critical mass.  This way they would experience
    >	the calls from customers first hand and *hopefully* close the
    >	loop on the problems that generate the most calls.  At some threshold,
    >	then transition the support to the CSCs.
    
    
    Great idea/solution! wonder if it was ever implemented ?
    
    Also, engineering who design and develop would have first-hand feedback
    from customers, especially early-on in the product life cycle.
    
    
    Regards,
    Edwin
    
    

    	It *had* to work like that when the company was smaller and more
    successful. When I joined DEC in software support I was one of three
    software technical people responsible for the whole of South-East
    England (yes, that includes London). Out of the 19 operating systems we
    had at the time I was given 6 to support. Fortunately there were fewer
    layered products then. There was nobody between me and engineering to
    support those operating systems and their layered products.
    
    	There was the feedback in all ways that you don't get now. When I
    needed source code to fix a problem I often had to contact the engineer
    to get it, and would send him back his fixed source code. Things I
    couldn't fix (for whatever reason, maybe just lack of time) went
    straight back to engineering. Since I was doing the pre-sales as well
    as remedial support, a product that was poor quality, or for which
    nobody had thought to provide me training, didn't get sold.
    
    	As for billing, well we didn't actually charge for software
    support. However, there was one problem that I thought I was going to
    have to fix - the operating system had only allowed 3 bits for the year
    field in the date, and this ran out in 1974. Obviously the engineering
    group was long gone for such an obselete product. Fortunately I was
    talking to the FS manager in the pub one evening, and he told me that
    the customer hadn't paid a FS bill in over a year....  The customer was
    told that since they didn't pay bills they could fix the operating
    system themselves.
    
    	Small companies can work that way, but it is not easy to see how we
    could get things to work that efficiently now.

Dave,

At those times it was different for customers as well. Customers could go and
buy source code for almost anything and use that as a last (sometimes the first)
support resource if everything else failed.

I worked for an OEM in mid '70 and started with RSX-11M Version 0 (not officially
published), when there were no manuals yet. I also started very early with
DECnet Phase II the same way. We had to do some additions and modifications
to fullfil realtime application requirements. Working even with engineering
had been impossible. I remember sending an SPR with a proposal to fix an NCP
error. I got a "thank you" message half a year later. Our project couldn't
tolerate that type of delays. It's difficult for an OEM to have a clause in
their contract saying that if Digital fails to support them, they are excused
from paying penalties.

With more complex systems and Digital's over-protective attitude against customers
above wouldn't work any more. It just seems, that services, which were supposed
to do the job, don't really fill the needs.

--Ritva

    
    	"Date '75" Oh I remember the problems that caused!  Didn't think
    any one else would remember it though!  I was a DECSYSTEM 10 FSE at the
    time.
    				Malcolm.

    
    RE: Cost of support
    
    How can we sell $1500 PC systems with 3 years of free service?
    Do we have a different service model for these systems or
    are we just ignoring the future liability of these machines?
    
    Jon

	If you build a product that does not fail in the first
	three (five,six,seven,etc), then you it doesn't cost you
	anything to service it.  If you build a product that fails
	in the first three years, then it costs you plenty. 
	Reliability is what is important.

    
    If your TV broke down in the first 3 years of ownership, I'm sure that
    you would be upset.  Why not expect the same thing for the PC?
    
    
    Mike

    >If your TV broke down in the first 3 years of ownership, I'm sure that
    >    you would be upset.  Why not expect the same thing for the PC?

    \Mikey, maybe because the PeeCeee is much more complicated than 
    a TV set? like, the PeeCeee has so many parts in it that can go
    wrong, Gateway gives one year, and i think almost every one else
    gives one year, few 2 years.

    you can't compare apples and oranges together, it is tear and wear
    and complexity of the machine involved, most PeeCeees last 3-4
    years then you need a new, from disk drive problems to things
    falling at the seems, this is just the nature of things, the
    PeeCeee has many more movable things in it than a TV which is
    just a receiving passive machine, while the PeeCeee is an active
    responding machine.

    hope this helps.

    \nasser

You can still lose your shirt. Customers can summon a tech to 'come fix
their PC' and the problem end up being software. If the tech is not
PC-software-literate then they can get sucked into an abyss.

Lee

    
    Well, my Father thinks differently, Nasser.  He says that there is no
    excuse for a failure within the first few years.  He seems to think
    that there is failure built in so as to sustain services business. 
    He's an electrical engineer and has designed and built power systems
    for spacecraft, some which have exceeded their life expectancy by over
    200%.
    
    
    Mike (who's not a techie so I have to go by what Pop says)

    I would never say that DEC does everything correctly, but come on...
    Sometimes the notes in here sound like DEC can not do ANYTHING
    correctly.
    
    DEC claims in our ads (and I believe this is true from my perspective
    in engineering) that our PCs are built to a higher quality standard
    than most others.  That's one reason for the PC prices we all like to
    complain about.  If you want to offer customers value for their money
    without lowering quality/price, it makes sense to offer a longer
    warranty.  It also displays confidence in our products.  If talent in
    diagnosing PC problems is lacking, it should be generated through
    training, not shortening of warranties.
    
    Tony

    re .30:
    
    >Gateway gives one year, and i think almost every one else gives one
    >year, few 2 years.

    >you can't compare apples and oranges together, it is tear and wear and
    >complexity of the machine involved, 

    Balderdash!  There are AT LEAST 2 local places even here in MPO that
    are selling boxes with 5-year warrantees.  And even with that they
    STILL cost less than the EPP price for ours.  And worst case, I've seen
    other places selling extended warrentees for 3 or 5 years for as little
    as $29/year.  I suspect there are places doing the same in your
    neighborhoods too.

In the previous project I worked on, we got frequent reports from our local
support group on the mumber of calls to the CSC and the number of calls for each
area of the product. These reports were given at least once per month.

We (Components and Perhipherals Video Engineering) have a support group only a
couple of aisles away. They are in contact with the CSCs and in close contact
with Engineering. I have talked to both customers and potential customers, and
have experienced some of the abuse someone referred to a few notes back.
(Support has a tough job!) Our group has sent engineers out to customer sites. 

I've also been pushing for customer input for the next project.

We even have the systems to test the product with VMS, Ultrix, OSF-1, SUN OS,
Solaris, AIX, HP-UX, and SCO, although this didn't come easy - we had to have a
lot of trouble with customers over an earlier product before we could get the
equipment we needed to properly test and support our products on 3rd-party
equipment.

Finally, all of this costs money, yet Components and Perhipherals has been
equalling or exceeding its budget. 

(BTW, the support group works for all of C&P products, hardcopy as well as
video, before anyone else points that out.)

.26>  	"Date '75" Oh I remember the problems that caused!  Didn't think
.26>  any one else would remember it though!  I was a DECSYSTEM 10 FSE at the
    
    No, DATE75 was different from DATE74. Same basic problem, different
    Operating System.
    
      John

    
    	My 2 week old XL is down and wont power up.  I work in service
    support and have been complaining loudly for the past month
    (decstation,ibmpc-94,infinity notesfiles) about the complete lack of
    documentation for this machine as well as system/scsi/video drivers.
    (customer shipable documentation)  I get responses like, it ships with
    the system so why do you need a copy to do your job.  I cant depend on
    customers to supply our tools, some get lost.
    	The question is should I summon an FE to my house or just bring it
    in myself?
    
    	I like the machine but unhappy its already on its butt.
    
    Mark

    
          <<< Note 2893.37 by VMSDEV::HALLYB "Fish have no concept of fire"
                                        -< nit >-
    
   >>> .26>    "Date '75" Oh I remember the problems that caused!  Didn't
   >>> think
   >>> .26>  any one else would remember it though!  I was a DECSYSTEM 10 FSE
   >>> at the
    
   >>>     No, DATE75 was different from DATE74. Same basic problem, different
   >>>     Operating System.
    
   >>>       John
    
    	Oh, Sorry, I didn't remember from nearly 20 years ago, that TOPS 10
    was on a different problem to the other Operating Systems.
    
    				Malcolm.

    	Just to clear up any doubt, the problem I was dealing with in 1974
    was with TSS/8 - up to 16 users time-sharing on a PDP-8. Many other
    operating systems and applications have had similar problems, and I am
    looking forward to the year 2000 when there will be a dearth of
    programmers as almost every programme in sight breaks simultaneously.

    	Part of service costs can be directly tied to lack of training.
    MCS has recently had most of the training cancelled ($$$).
    	Another nit with me is:
    	The OSF Services advisory (OSF 1.2) was one of the best CSA
    I've seen, and in the hands of MCS engineer with little or know
    UNIX experience could T.S. an OSF machine well enough to make 
    an educated guess as to what is wrong.
    	The people who wrote this were forced to take other jobs, and
    so this DOC will NEVER be updated.
    RECENT EXAMPLE:
    	Customer compains his OSF disk will not boot, andclaims bad disk.
    MCS replaces disk (rz26).
    	I check the disk and finf out that genvmunix would boot, vmunix
    wouldn't. Somehow the vmunix was built with WRONG CPU ident.
    	The MCS person involved is highly skilled, but lacks UNIX
    experience.
    		dick
    

    
    Re:  41
    
    Dick,
    
    Where can I get a copy of that services advisory document?
    
    Colin
    

    Try ahlem::/usr/guest/v1.2/advisory.ps or advisory.ps.Z
    
    	marty

    
    -1
    
    Thanks.  Someone saw my note and brought around a copy.  I'll
    see what I can do to get some of this information rolled into
    the current docset.
    
    Colin