Conference 7.286::digital

    
    OK Lee, I'll bite.  What is Digital?  Use to be an engineering company
    which designed, built and serviced "it's own" computer gear.  Today?
    Seems as if we still manufacture some of our gear but appear to be
    going through metamorphic stage of redefinition into a
    service/solutions corp.  At times these changes in corporate direction
    appear to mysteriously leak out from above.  Has the change occured?
    Not totally.  Will change become the normal way of life at DEC?  In my
    eyes, yuppers!  What will the end product (DEC) look like in 10 or 20
    years from now?  Don't know.  Will I still be gainfully employed here?
    Don't know that either.  Which brings me to the your second question
    and more to the point.  What does DEC mean to me?  At present, a job
    which allows me to pay my bills from month to month.  It still provides
    me with the opportunity to learn and grow.  It's a place where I still
    enjoy seeing co-workers, ah...that's most co-workers.  It's a place
    that I can leave at the end of the day and go home to my family.  Will
    DEC, more specifically this site be here tomorrow fo me?  Can't answer
    that one either.  Will I still be gainfully employed next week?  Don't
    know.  The point is, if I'm TFSO'd or the site closes in the future
    am I to no longer exist?  Don't believe so because I know there is 
    "Life after DEC" out there somewhere....just like there was "life
    after (your last job)!"
    
    djr

    re: .0
    
>View #2: Others are of the camp that Digital is just a company and you
>are just an employee, a 'resource' to be kept or discarded at the whim of
>management, whose current plight is due to the failings of 'those at the
>top'(aka 'them') in management rather than the rank-and-file
>employees(aka 'us'). Those with View #1 need a reality check.
    
    Ahhh, the magic word: "resource".  This is a key to our situation.
    
    While I can understand those who espouse View #1 ("The High Road"),
    there are many who find themselves adhering to View #2 ("The Low
    Road").  Lee has correctly correlated the use of the tag "resource" to 
    those who take the Low Road.
    
    It is hard to hold to the High Road when your own management obviously
    holds to the Low Road.  Around here, our management never seems to
    speak of "people" or "employees".  Most official communication seems to
    refer to "resources".  The chair, the lamp, the computer, the
    specialist... all are resources.  When someone is needed to fill a
    technical need, do we get a message saying "We need someone with mumble
    expertise to perform a nn week assignment in West Futzburg"?  No, we
    get a message saying "mumble resource required for nn weeks in West
    Futzburg".
    
    One may "empower" an employee or a person.  After all, people are
    capable of self-initiative.  However, one NEVER "empowers" a resource.
    Resources are to be used.
    
    Any talk of "empowerment" is clearly self-deception as long as those
    above you make it clear that you are nothing but a resource.
    
    If someone REALLY WANTED to raise morale and guide us toward the High
    Road, then he or she should BAN the use of the term "resource" as
    applied to human beings.  We've made it improper to use terms like
    "babes" for women and racial slurs, so why should we encourage the
    demotion of people to a sub-human level?
    
    -- Russ

Ok, cheap shot:

>Use to be an engineering company
>which designed, built and serviced "it's own" computer gear.  Today?

Hot off the usenet wire:

Article 54210 of comp.os.vms:
Path: ryn.mro4.dec.com!nntpd.lkg.dec.com!pa.dec.com!decwrl!mips!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!ucbvax!OCVAXA.CC.OBERLIN.EDU!CMATT
From: [email protected] (Matt Gilbert)
Newsgroups: comp.os.vms
Subject: Can someone explain basic DSSI config?
Message-ID: <[email protected]>
Date: 14 Jul 92 17:44:00 GMT
Sender: [email protected]
Organization: The Internet
Lines: 19


   Well I've really done it now. I tell'em buy a 6620, DSSI and a bunch of
RF35's. Now that I've got them, what do I do with them and how do they work?

   Can someone please explain the basics of DSSI? I am missing something 
fundamental, in that I do not understand why my KFMSA's (2 of them) need
node names/numbers, alloclass numbers, etc. It looks as though each of 
these controllers appear to the host as 'virtual nodes' serving their disks
to the host.

   BTW: It's a single host 6620, no cluster. VMS 5.5, 2 KFMSA's, 12 RF35's
and 2 RF73's (this would be a really nice machine if I could figure out how
it works). My DEC field engineer is just as in the dark as I am (actually I 
think more so).

Matt Gilbert
[email protected]

    
      re: .3, ELWOOD::Lane,
    
    I can't stop laughing!  Thanks for the humor this afternoon...........
    Reminds me of the farmer who purchased the latest and greatest
    tractor with all the fix'ns and can't find the ignition switch
    while all the produce in the field goes to pot!
    
    djr

    
    RE: .4 
    
    � ...can't find the ignition switch
    � while all the produce in the field goes to pot!
                                         ^^^^^^^^^^^
    Perhaps the farmer is not looking for the ignition key.
    
    
    

    
    "What is Digital to me? "
    
    Timely question. I guess Ken was asking this very same thing this 
    morning. 
    

    RE .3
    
    >> Can someone please explain the basics of DSSI? I am missing something 
    >> fundamental, in that I do not understand why my KFMSA's (2 of them) need
    >> node names/numbers, alloclass numbers, etc. It looks as though each of 
    >> these controllers appear to the host as 'virtual nodes' serving their 
    >> disks to the host.
    
    Tell Matt to read chapter 5 of the KFMSA Installation & User Manual.
    The information he seeks is in there (I know, I wrote the book).
    
    >> BTW: It's a single host 6620, no cluster. VMS 5.5, 2 KFMSA's, 12 RF35's
    >> and 2 RF73's (this would be a really nice machine if I could figure out
    >> how it works). 
    
    Well, if he'd spend a little time perusing the DECarray Installation 
    Manual he would be able to "figure out how it works".
    
    >> My DEC field engineer is just as in the dark as I am (actually I 
    >> think more so).
    
    Now that's a shame, considering all the service guides and training
    courses available for DSSI products.  I'd say either the DEC field
    engineer has been negligent in paying attention to his products, or
    his (her) manager has been negligent in getting their field engineers
    trained.  DSSI is not a simple product ... there are many available
    combinations for many possible applications.  You simply cannot go
    out into the field and "figure it out".
    
    ... Bob (who spent more than five years writing product manuals for
             DSSI products)
    

    re.3

    What's really sad about the whole thing is not that the
    manuals/training/support don't appear to used, but that the call for
    help went out on the usenet. The answers that this person needed were
    only a simple phone call away (that either (s)he or his/her field
    engineer could have made). The CSC's handle more that a hundred DSSI
    related calls every day. Ok, maybe a few less on the weekends. But the
    point is; If you have an internal problem, why go outside.

    Frank Mueller
    Remote Support
    CSC/AT

    Gee, maybe I can get a job as a DSSI consultant on the usenet after
    TFSO.  :-) 

    
    Sorry the last reply was for .7 not .3
    
    Oh well,  so I can't type.
    
    f.m.

    RE .8
    
    Couldn't agree with you more Frank.  But notice the call went out on
    usenet after the field engineer couldn't supply the knowledge.  This is
    really a problem ... those products were never intended to be customer
    installable, and a field engineer HAS to have the concepts down before
    going to the customer site, or we all look like fools who can't even
    support our own products.  It tends to give us all a black eye, even 
    though hundreds of thousands of dollars went into making sure everything
    was in place to support these products and prevent this sort of thing 
    from happening.
    
    This is indicative of one of the really frustrating aspects of Digital
    culture that is, in my experience at least, unique to us.  One part of
    the company can spend massive amounts of money developing a product,
    and the necessary support for that product.  And another part of the
    company can make a unilateral decision not to make use of the resource,
    essentially wasting all that effort and money.  We can produce the
    information that a field engineer needs to install one of our products,
    but we can't make that field engineer read the manuals, or attend the
    training courses.  The feedback I got from the field when developing
    this information was that the field engineers wouldn't be allowed the
    to take the training because of the time it took and the money that it
    would cost their cost center.  Apparently, this was accurate feedback.
    
    So they save a few bucks off their bottom line operating costs at a
    field office or CSC.  Then the customer calls for help and they don't
    know what they're doing.  Or worse yet, they go to a customer site and
    botch the installation.  The customer gets upset and puts something 
    like that note on usenet, for all the world to see.  Digital gets yet 
    another black eye, and maybe loses yet another customer.
    
    Who wins?  The manager who decided not to train his or her employees
    perhaps ... their spreadsheets look pretty good.
    
    Who loses?  Everybody else at Digital ... we've spent big $$ developing
    knowledge that doesn't get used.  Our customers lose confidence in our
    ability to support our own products and decides to take their business 
    elsewhere.
    
    What's wrong with this picture?
    
    						... Bob
    

    >>          <<< Note 1991.10 by CUPTAY::BAILEY "Season of the Winch" >>>
>>
>>    
>>    What's wrong with this picture?
>>    
>>    						... Bob
>>    

    Bob,
    	Everything is wrong with it.  It is what the Field calls a warm
    body on site.  We as a company are not committed to train our Field
    personal properly.  I am sure this extends to other areas of the
    company, but I am not familiar with them.
    	An example is the 8800.  When it was released only level 2 trained
    F.E.'s were allowed to work on the product.  Somewhere that LAW was
    lost.  We send anyone out.
    	I work in the customer support center in Colorado.  I see lots of
    calls where an untrained F.E. is on site.  What does the customer
    think?  All in the name of keeping a Districts budget in line.

    Jim Morton

.0>  View #2: Others are of the camp that Digital is just a company and you
.0>  are just an employee, a 'resource' to be kept or discarded at the whim of
.0>  management, whose current plight is due to the failings of 'those at the
.0>  top'(aka 'them') in management rather than the rank-and-file
.0>  employees(aka 'us'). Those with View #1 need a reality check.
    
    The three views presented in .0 omitted one other possibility.  View 2
    is stated in terms of "us" rank-and-file employees vs. "them"
    management types (a/k/a "suits").
    
    An alternative statement of View 2 (from a non-Noter perspective?) might
    be:
    
View #2(b): Digital is just a company, with employees who are just 'resources' 
to be used by the corporation, whose current plight is due to the failure of 
'the rank-and-file employees'(aka 'them') to be productive rather than the 
failure of 'management'(aka 'us') to set the right direction.  Digital 
could really get going if we could just ditch those deadwood employees.  
Those with View #1 need a reality check.
    
    Of course, it is implicit that the direction Digital gets going is one
    that leads to success...

    I agree that it is a shame when a field engineer goes on site
    and doesn't know the product he is there to support.  Don't
    blame the f.e. or his manager.  Most field units get a budget
    for training for approximately three weeks per year per field
    engineer.  That is for everything, new hardware and software
    products and now the f.e.'s are expected to know software 
    (at least to install it).  So yes, many times a f.e. will go
    on site and do his best and yes, he probably hasn't been trained.
    Manager's think nothing of sending an untrained f.e. on site.
    Why do you think the csc gets so many calls from dec people.
    
    Sorry, this is one topic that really gets me upset.
    
    Nancy

    What a bunch of baloney!
    
    Yeah, it's the field engineer's fault.  Everything you need to know
    about installing and using an 8800 is in the 5 volume 8800 maintenance
    manual.  I've got one right here!  3 volumes for a decserver 100.  The
    8800 level 2 course requires 6 months of prerequisite courses.  The
    8800 was such a BAD product it alone is what drove me out of working on
    CPUs.  To properly diagnose any VAX on site your need 18 pounds of
    microfiche, which sometimes is updated by engineering and sometimes
    not.
    
    Field engineers?  What about software specialists?  Hey! We just got a
    support contract to customize a VTX application for (fictitious name)
    Dewey, Cheatham and Howe.  Who's available?  Field service call for 2
    hour response contract?  Who's available?
    
    We are not any different from any other major manufacturer.  'Big Blue'
    does the same thing.  Evans and Sutherland, Cray, Unisys, H.P..  You
    get to meet a lot of people on-site and watch them do the same things
    we do, and for the same reasons.  Field service has a committment,
    software services have committments, they have budgets.  They need
    training from some kind of Ed services, who have budgets and overhead. 
    Ed services gets its training from Someone else.  Other
    committments/priorities/budgets/schedules.  Believe it or not, in DEC,
    those people get their training from someone else with another
    budget/priority/schedule.
    
    Field service would need to train ALL the people who would EVER
    encounter a particular device in the field.  Travel expenses alone get
    to be a significant part of the budget (airfare, food, lodging,
    et.al.).  Software Services would need to train ALL their people on ALL
    of the products and ALL of the patches/bugs/workarounds/eratta.  It can
    be done but not in the product's lifetime.

    RE .14
    
    You can come up with all the "good" reasons in the world why we send
    untrained "warm bodies" into the field.  But that doesn't make it right.
    Our customers depend on us to make sure that the equipment we sell them
    gets properly installed and does what we say it does.  If we can't
    deliver on those promises, then we deserve to lose their business ...
    it's that simple.
    
    If F.E.'s aren't getting the training they need to get the job done,
    then something needs to be changed, not justified.
    
    ... Bob
    

    A big part of the problem is not necessarily training, or lack there
    of, but instead it's resources. Yes, I work in a CSC and yes I am a
    resource to the Field Engineer. But no, I am not here to do his or her
    job for them and I do not work for 1-800-do-my-job. I am here to help
    those who need help regardless of why they need help. It's a shame
    that FE's get sent to site with no documentation and or product
    knowledge, but it's something else all together when FE's or SWS's or
    Sales goes to site totally unprepared and expects someone else on
    the other end of the phone to do their job.

    Often we are expected to work on or support or whatever things that
    we may not have an "expertise" on. This is why the CSC's and other
    resources were created. But much too often these resources are either;
    a) not used until the person has spent too long onsite and is dead in the 
    water (in which case the customer thinks that the person is incompetent)
    or  b) not used at all.

    Don't get me wrong. I think DEC is a great company and I think that
    there are a lot of great people working here. But, we need to work
    together if we are going to have any success at all. 

    Dismount soapbox.

    Thanks for listening,

    f.m. 

While we're improving training and field resources, maybe we should
also elevate the priority of building systems that are simple enough
that they don't require 18 pounds of microfiche and six months of
training just to be maintained.

   Gary

Consider this:  the guy calling you from a customer site may well be a HIGHLY
trained specialist who's just been asked to deal with something totally outside
his skill set just because he happend to be there.  


Unprepared?  Of course!  She went on site to fix their Rdb database, not an 
SNA problem.

RTFM?  Have any idea how many customers have managed to "misplace" half their
documentation?

\dave

    
    Also, consider the situation in field resources today:
    
    You have 8-10 SW specialist in large office and 2-3 in small office
    for customer on-site assignment.
    
    And they need to support from ULTRIX, SCO, OSF, VMS, PC, Pathworks,
    RDB, ALL-IN-1, DECnet, never mind rest hundreds of layer product.
    
    The way how we structure our support layer is another topic for
    management. Another point, mentioned earlier already, is how to
    make easy-of-use & maintain product by engineering. 
    
    Would you think it will be easier to be a Microsoft field support
    people, by product array wise ?
    
    Michael..
    

    
    
     I've been in the field for over 13 years and there was a day when we
    could carry enough manuals in out vehicles to support about 85% of the 
    systems/options we supported. Things like 1170 pocket guides, the 
    11780/750 black books, and orange UDA50/RAXX books. Even with
    microfiche we couldn't do it today. I can work on a VAXcluster in the
    early morning, a SUN sparcstation after that, then maybe a HP Laserjet,
    or RM05 disk, or PDP11/84. I never know what a day can bring. I got a
    call this morning on a DEC LJ16P. I had to look at the DEC direct catalog 
    to find out WTF it is! The CSC is one of our most valuable resources
    for that very reason, we are more generalists than specialists. Those
    days are gone when an engineer says "I don't work on large disks" or
    "I don't work on anything that doesn't say DIGITAL". 
    
       Half of being a Field Engineer is knowing (and correctly using) your
    resources!
    
    							-John R-

    It would be great if a specialist, an expert on EVERY product, system
    and application was ALWAYS available (24 hours, 7 days a week) to assist 
    everyone.  (Imagine the costs?)

    Many customers expect that service engineers who are specialized experts 
    be available for every one of our (hundreds?) of products on on every call,
    at all times.  Many remote field offices have only a few people in the 
    local office.  Some work from their homes and have no local office nearby.  
    Those folks do a fantastic job with the tools and training available,
    IMHO.

    re .19
    
     Don't forget support of third party products too. We are systems
    integrators.
    
    Mike Zarudzki
    Digital Services on-site

    RE: .21  Marty,
    
    			Thank you for your kind words....I am one of those
    "remote's" you speak of.  Sadly, its going to get a lot worse with
    TFSO.  Its almost to the point of diminishing returns.  I sometimes
    have to travel 3 or 4 hours just to get to the site...DECSERVICE no
    less.  Without remote support and the library, I would be in *DEEP*
    trouble...and more importantly....the customer, who after all is the
    main focus.  
    
    			I wonder now what the "burn out" rate will be for
    those of us "remote's".
    
    Dave

    Dave,
    	Have no fear, Remote Support and RDG and the Library will still be
    here, even after the TFSO.  We will just have more to do after the
    cuts.  We will do the best we can to maintain a high level of service.

    Jim Morton (Remote Support)