Conference 7.286::digital

    re .0 -
    
    since you know where this came from, can you post a rebuttal including
    the fact that Security patches to the operating system ARE distributed
    to customers?  The security patches often do not identify the problem
    they fix for security reasons....
    
    Martin

    Just a few words.
    
    I've just finished a contract at another Digital site were we spent
    three weeks with the CSC in Basingstoke identifying a problem that had
    a known fix, for a customer in Italy.
    
    The CSC only gave out patches to reported problems (re.0) and the
    patches are only supplied to a mailing list held by central engineering
    in the US.
    
    A simply mail once a month to all known OSF license holders/system
    managers would have saved all off this grief.
    
    The problem descibed tied up:
    2 engineers on site in Italy.
    1 engineer in the Digital office in Italy
    2 engineers (including myself)
    2+ engineers in the CSC.
    
    If just one of us outside of the CSC had known about the patches we
    could have applied them and the known problem(s) would have gone away.
    
    Enough for now.
    
    AndyH

re.0:

What did the manager of the CSC say when confronted with this?

Dave.

    
    Giving a patch kit to a customer is always a risc ... it isn't tested
    like a "formal produced version/subversion". In my opinion it isn't a
    good idea to give the customer access to each existing patch.
    
    Anyway - if the customer has a contract to use AES (advanced electronic
    support) he can get access to TIMA/STARS patches + problem description
    which are classified for widely usage.
    
    Send the originator of the mail a support contract for AES ;-)
    
    Vera
    
    p.s. for internal use most of the existing patches (more than a
    customer can access) are accessible via TIMA/STARS - you only need
    an account on one of the systems (which one and where to ask for is
    available in your local CSC)

The following was announced June 1, 1994.  It includes information about
accessing patches from the internet and perusing known problems.

regards,
	jennifer simon
	UNIX partner
***************************************************************************
From:	NAME: Readers Choice                
	FUNC:                                 
	TEL:                                  <CHOICE.READERS AT A1 at SALES at MRO>
To:     See Below

From  Karen Quatromoni, (508) 264-5358, [email protected]

								Booth # 425

                 DIGITAL ANNOUNCES NEW COMMERCIAL INTERNET

                    CAPABILITIES AT INTERNET WORLD '94



INTERNET WORLD, San Jose, Cal. -- June 1, 1994 -- Digital Equipment
Corporation today announced new commercial Internet services and
showcased its Internet support capabilities under the theme, "Putting the 
Internet to Work for You." At Internet World, Digital is showcasing its 
abilities to help customers effectively utilize the Internet.

"As commercial uses of the Internet have expanded, Digital has been in the 
forefront in finding creative ways to use this technology to meet customer 
needs," said Dr. Samuel H. Fuller, vice president for Corporate Research.

At Internet World, Digital announced:

     o 	The Internet Electronic Connection: Ordering over the Internet

     	Digital today becomes the first vendor in the computer industry 
        to provide complete, consolidated electronic information and 
        ordering over the Internet. Through easy-to-use menus, 
        commercial customers now have the ability to obtain current 
        descriptions of Digital's hardware, software, services, and 
        third-party products, plus read the latest announcements of 
        special offers and new products, and find pointers to many 
        other Internet services. Users in the U.S. can also configure 
        systems, generate price quotations, and place orders, a 
        capability which will be extended worldwide in the future. 
        Customers may register on-line for an Internet Electronic 
        Connection account by using telnet to reach 
        Orders.Sales.Digital.Com

     o 	Digital Internet Services:  Software Patches via the Internet

     	Digital service and warranty customers in the U. S. will be 
        able to access all software patches via the Internet. Patches 
        to the ULTRIX and OSF/1 operating systems are now available, 
        and patches for the OpenVMS operating system will soon be 
        available.  This gives service customers the ability to log 
        into a system (via FTP) to pull patches on their own 
        initiative, rather than having to log a call with the Customer 
        Support Center (CSC) and then the CSC shipping the patch to the 
        customer by conventional means. 

     	An online search utility is also available under the World Wide 
        Web interface to allow for keyword searches thru the the 
        release notes, patch descriptions, and READMEs for all patches. 
        This will assist customers in  locating patches designed to fix 
        problems they have identified in their own  environment.

This and other Digital Web offerings can be accessed from node: 
www.service.digital.com (The URL is: http://www.service.digital.com/home 
html) For more information regarding either the FTP Patch Service or  
Digital's Service Webserver contact [email protected]. 

Digital demonstrated these new capabilities as well as its recently 
announced comprehensive Internet Security Services to help make private 
computer networks and databases secure from intrusion from the Internet. 

Digital's Internet Security Services include: 

     o  Screening External Access Link (S.E.A.L.) - a 
        combination of custom security consulting, Internet 
        security policy development and rules definitions, 
        installation and configuration of customized software, 
        training in all facets of S.E.A.L.'s operation, and
     	post-delivery telephone support. 

     o  Optional components and consulting which include: 
        additional customized application gateways; 
        configuration of public domain software; cryptographic 
        and authentication capabilities; and computer and 
        network security consulting.

Digital also demonstrated its participation in CommerceNet and MecklerWeb 
(see separate release), two commercial Internet services. The City of Palo 
Alto and Wells Fargo Bank -- two customers for whom Digital set up World 
Wide Web servers -- will be in the Digital booth to demonstrate the 
capabilities of their servers.

Digital has been a long-time supporter of the Internet; for example, 
providing systems that act as relay points for newsgroup communications, 
and  developing public domain software like FTPmail, which enables users 
with  limited electronic mail capabilities to access remote files. Digital 
is also a sponsoring member of the non-profit CommerceNet consortium, which 
is  building an open, Internet-based public information network that 
features services and applications that meet the reliability, security, and 
access needs of commercial organizations.

The one-year-old Alpha AXP Internet program enables Internet users to test 
drive Alpha AXP systems for free, evaluating the Alpha AXP architecture 
using their own applications. Users can  select systems running either the 
DEC OSF/1 or OpenVMS operating systems,  and configurations range from 
workstations to servers. To access these systems, customers should telnet 
to the desired system and log in as axpguest (no password) and fill out a 
short questionnaire. 

Systems currently available include:

     	axposf.pa.dec.com (DEC 4000 Model 710 AXP server running 
        DEC OSF/1 operating system)

       	axpvms.pa.dec.com (DEC 4000 Model 720 AXP server running 
        OpenVMS AXP operating system)

       	axposf.stanford.edu (DEC 3000 Model 800 AXP workstation 
        running DEC OSF/1 operating system)

       	axpvms.cc.utexas.edu (DEC 3000 Model 800 AXP workstation 
        running OpenVMS AXP operating system) 

Digital Equipment Corporation is the world's leader in open client/server 
solutions from personal computing to integrated worldwide information 
systems.  Digital's scalable Alpha AXP platforms, storage, networking, 
software and services, together with industry-focused solutions from 
business partners, help organizations compete and win in today's global 
marketplace. 
                               ####

Note to Editors:  Alpha AXP, AXP, DEC, Digital, the Digital logo, 
                  OpenVMS, and ULTRIX are trademarks of Digital 
                  Equipment Corporation.

     		  OSF/1 is a registered trademark of the Open 
                  Software Foundation, Inc.

CORP/94/507

Distribution:  
You received this message because you subscribed to the Press Releases in 
Readers Choice.  To add or delete your name from this list use the VTX keyword 
PROFILE.

For Canadian subscribers at your ACCESS main menu, select option #10 for
News/Information Service and then Option #7 for Readers Choice."

If you have questions, please send mail to Readers Choice @MRO or 
SALES::READERCHOICE.

UNIX Users:
- to send VAXmail:    [email protected]
- to send ALL-IN-1:   [email protected]





To Distribution List:
(deleted)

re: .5 <  Patches available on Internet... >


After reading note 697.*, titled: 'Internet patch service announced', in
notesfile internet_tools on sofbas::, I would suggest *personally* try it out
first before showing it to customers!

Another reference info, how patches/fixes made available to customer, I ran
across how IBM does it on Internet, check out:

URL: http://www.austin.ibm.com/services/aix_service/

I got it via IBM's homepage, and I even retrieved several fix articles
from it, via Internet, with no problems. Btw, they don't call it 'patch',
they call it 'fix'.

Also, I don't know how long can a company get away with charging customer's
for fixes/patches for product bugs? Doesn't the company owe its customers
already when product bugs caused damages to its customers? 

Regards,
Edwin

    It's not just the U*IX market where we have a problem.  Most customers
    in the IBM mainframe world are used to receiving a periodic PTF
    (Program Temporary Fix) tape along with an extensive catalog listing
    known bugs, the PTF to fix, prerequisites and cautionary notes.
    
    These folks generally think our "first YOU find it, then we fix it"
    policy verges on insanity.
    
    \dave

    I used to be responsible for an IBM commercial shop's "system
    programming", which means keep the system software running. Our IBM
    services guy had his own office and he was in every other day or so.  
    In his office was a big pile of these PTF tapes, and he had a program
    with a searchable database that contained descriptions of all the
    fixes.  New tapes arrived all the time.  The database covered every
    piece of IBM software we had - os, compilers, databases, etc.
    
    Our policy was never to install a PTF unless we were experiencing
    the bug, as some of those fixes were themselves buggy.  But with
    his database and having all the fixes right there, the time between
    walking into his office with the problem description and him going
    out into the lab to install the fix was sometimes under an hour or two.
    
    This was almost 20 years ago.

    I must admit that if I were responsible for running a production 24x7 
    environment, I'd be very careful about the blanket application of patches 
    to my systems.
    
    Shipping products go through fairly rigorous testing during their
    field tests; not quite the same rigor being applied to the patch
    mechanism...  Trouble is, how do you spin this for customers ?  I
    really understand the frustration, though.....
    
    How do other vendors handle this ?
    
    -Dave.
    
    

> Shipping products go through fairly rigorous testing during their
>    field tests; not quite the same rigor being applied to the patch
>    mechanism...  Trouble is, how do you spin this for customers ?  I
>    really understand the frustration, though.....
    
>    How do other vendors handle this ?

Well, SOME other vendors do not have rigorous testing.  (field tests???)
so, for them, its not a problem to issue a patch with the same level of 
testing as their normal production releases...

I once had another vendor's database product blow away my process for the
crime of exiting out of the debugger without closing the database...  Seems
they had NEVER tested without full privs on...

I'm not so sure that Digital is as badly off as .0 implies.

We do have the DEC Std 204 process for putting out maintainance kits. 
These kits can, and do, go on the CONDIST CD-ROM. These kits contain
release notes that describe the problems that are fixed.

There are about 3 chances per annum to get on a CONDIST. So we must
be almost as good, if not better, than IBM's periodic PTF service.

Now I know that not all Software Groups put a refresh on every CONDIST.
But Digital has created the process to do this. So it's not Digital's
fault that customers don't get fixes, it's down to each engineering
and support group.

Mark

�But Digital has created the process to do this. So it's not Digital's
�fault that customers don't get fixes, it's down to each engineering
�and support group.

EXCUSE ME? (I KNOW I'M SHOUTING; I LIKE TO SHOUT ;-))  Are you trying to tell 
us that this is what we should tell our customers?  What planet are you from?
Remember the transitive property from  fourth grade mathematics?  It, sort of,
applies: 

   Mumble is B's "fault."  
   A is responsible for B.  
   Therefore, mumble is A's "fault."

Or better yet, and more simply: Aren't you engineers paid by the same Digital as
I am?

Sheesh!  You talk about stovepipes.  You talk about finger-pointing!

We've have to be one company with no excuses.

That's all.

Bruce

DEC 204 is The best process in world, I'm sure.   Doesn't solve the customer 
problem, but don't blame the process.   All hail the mighty process!

Sheesh...  I can't believe there are still people in this company that are
so isolated from reality.

Bob

    
    
    it has long been my understanding that digital-wide, customers
    are deliberately *not* proactively notified of the existence of
    patches...even patches form products for which they have purchased
    a support contract for.  if this is true, and ms. pitt is in a
    position to confirm/repudiate this...then in my opinion that support
    contract is fraud.  also, i wish i had a nickel for every customer that
    has complained "you knew there was a patch to this product and you
    didn't give it to me???!!!"
    
    digital, on the otherhand, likes to delude itself and its customers
    into thinking that our software is bug free...which is the only defense
    i have ever heard from not poractively offering the software patches.
    
    mark
    

    at least in some cases, customers DO have access to all of our patches. 
    for those with DSNlink or DSIN (presumably DIA at some point in time),
    simply open, say, the VMS database and search for PATCH or CSCPAT or
    whatever.  there are loads of them out there right now!  with DSNlink
    (and presumably DIA at some point in time), you can copy the patch
    right to your system in real time.  we do use our electronic tools to
    tell customers about the bug fixes.  it happens all the time!

    
    
    re: -1
    
    the issue is proactively offering patches.  DSNlink does offer 
    DSNlink customers access to patches that're discussed in a STARS
    article...but the customer first has normally uncover the problem
    him/herself and then peruse the STARS articles looking for a solution
    and would normally only *then* stumble onto the patch that may be
    refereneced in the STARS article.  correct?  this is not my idea of
    proactive!
    
    now if software patches were always announced in flash messages
    sent out to DSNlink customers i think we'd have a better leg to stand
    on.
    
    mark
    
    

RE: .12 MBALDY::LANGSTON

Go and read .11 again. We *DO* have a process whereby maintainance can
reach customers on the CD-ROM. 

Go find out what it is and then we can discuss what's wrong with it.
M

    re .8, .9 and others
    
    The IBM patch management S/W (called SMP/E) provides very sophisticated
    facilities.
    
    As far as I can remember (3 yrs ago..), as well as hundreds of PTFs
    every month, you also got info on which of the last few months PTFs
    were subsequently found to be flakey. Also, pre-requisite and
    co-requisite PTFs were identified (all in a format that the SMP/E
    utilities understood). Every month, we unloaded all PTFs into a
    database, and routinely applied PTFs that were older than x months,
    provided they were not flagged as 'bad'. Again, the utility did it all.
    The real joy, however, was in removing one particular fix should you
    need to..... all the other fixes that needed to be pulled off came off
    cleanly ('cos SMP/E kept track of it all for you....). [Note: 'x' was
    variable, depending on the type of product you serviced.]
    
    Regular distribution of patches is just part of the solution.
    
    
    AW

It's part of my job to produce patches and fixes for various things so
maybe I can share the view from the other side of the street.

It's my opinion that patches fall into two categories - those that fix
some fundamental flaw in the product and those that modify the design
of the product to comply with some customer's "odd" use of it. "Odd"
does not mean illegal.

The first type of patch is often made public by means of blitzes, etc.
and is often quickly replaced by a new release of the product.

The second type of patch is often hidden from public view because it's
VERY expensive to update all customers and the only one who actually
benefits is the customer with the initial complaint.

From time to time, another customer comes along with the same "odd"
configuration, etc. and someone pops up and says "Oh, yeah, we fixed
that one." We then have the situation described in the previous notes.
If too many additional customers show up, the patch goes from the
second gategory into the first.

The whole thing is a judgement call. No engineering group likes to
have ANYTHING wrong with it's product but they are faced with the
same financial pressures as every other cost center. It's a tradeoff
between (endless :-) designing and testing for variations and the
amount of time and money available.

As an aside, take the time to compare DEC's products with some of the
stuff in the PC world. With PC stuff, sometimes you don't get a fix,
you get instructions to "don't do that! Do this and only this..."
They make it work well enough to sell and that's that. If you don't
use it EXACTLY like they designed it, it's your fault, not theirs.

Mickey.

    No, it's not a "tradeoff;" it's an elementary application of quality
    theory.  Reply .20 confirms the fact that fixing a problem is most
    expensive at the end; it is in fact cheapest (i.e., free) to have no
    bugs at all, but next best to fix them as early in the cycle as
    possible.  
    
    Engineering should bear the costs of field updates, or at least be made
    fully aware of them, and that data should be part of the calculations
    of the cost of product development, so they can know what they are
    really doing (and costing Digital).
    
    This is also an elementary application of customer satisfaction.  Maybe
    sending out patches is expensive, but how expensive is a dissatistifed
    customer?  Does the customer drop Digital and tell two friends not to
    buy from us?  Do they tell two friends (and so on, and so on...)?
    Deming said to manage by the unknowable numbers as well as the knowable
    ones; this is what he meant.  I should think we'd be looking to
    differentiate ourselves from our competitors (we give you bug fixes)
    not hide behind their performance (everybody does it, customers only
    have to ask, why don't they accept our way of doing things?).

re: .20

Justify the loss of customer goodwill in the following actual case from 8 years
ago:

Known  bug: Creating a field with more than 'x' bytes in one of our database
products corrupts the database, requiring restoration from backup.

Did we tell customers not to create fields with more than 'x' bytes? No.

Customer calls in with corrupt database due to field being more than 'x'
bytes long.  Told to restore database from backup.

Restoration from backup fails.

Known bug:  Databases with fields with lengths greater than 'x' bytes are
backed up incorrectly, rendering database backup unusable.

Did we tell customers not to create fields with more than 'x' bytes.  No.

Problem resolution:  Customer creates new empty database and reenters data
by hand.  Spends many hours modifying database and applications to use 2
fields shorter than 'x' bytes, praying that nothing gets corrupted again in
the meantime.

Digital response:  Fixed in a future release.

How do I know all this?  I was the customer.  Had I been in management rather
than the system manager, Digital would have had a major customer satisfaction
issue and a possible lawsuit...can you say negligence?

re: PC software - Digital software doesn't cost $69.  If Quicken eats my
checkbook data, I go to backups and/or revert to paper until the problem is
either fixed, or I buy a product from another vendor that doesn't have the
problem.

Bob

re: .21, .22

I'm trying to explain what the situation IS, not what it's supposed to be.
I don't particularly like it either.

Re tradeoff - yes, it is a tradeoff. You do what you can with the materials
available. If that's not good enough, get more materials or change what you
set out to do.

    I have a Mission Critical Support customer and with their contract they
    have Propatch run every month or so on there system.  What Propatch
    does is run on the customers cluster, compiles a list of patches that
    the customer may or may not want to apply, prioritizes them in three
    catagories from critical to low priority and then notifies the customer
    of the list. The customer then reviews the list and decides which
    patches to install.  This is a very good tool, I as the service rep
    like it because I don't have to keep an eye out for any patch they
    might need and the customer likes it for basically the same reason. 
    The only bad part is it seems only Mission Critical customers recieve
    this service.  I know it would be expensive but if more customers could
    have this run on their systems, I believe alot of the previously
    mentioned problems could be avoided.
    
    stu
    

    Patches are only part of the problem.  The inability to identify known
    bugs BEFORE you experience them is an ongoing frustration for
    customers.  If you know a feature doesn't work, it's usually easy to
    design your code so as to avoid it.  Once you've used it EVERYWHERE and
    then find out there's a bug, you have a major problem on your hands.
    
    The scenario in .2 has been repeated, more or less, in at least half of
    the customer shops where I've done consulting.  In one case, the bug
    was not only "known" but it was so serious that a decision had clearly
    been made to hide its existence!
    
    \dave
    

Patches are fixes to specific problems and are not fully
tested. If we made all patches available to customers, then
we would only have to pick up the pieces at the other end
when knock on effects of installing conflicting patches
start occurring. It makes sense to supply customers with
patches when, and only when they need them. As .20 said,
a lot of problems fixed by patches are never even met by 
the customer, so sending them these patches is not cost
effective.

	Ian 
	UK CSC, Basingstoke

    re: .25
    
    > The inability to identify known bugs BEFORE you experience them is an
    ongoing frustration for customers.
    
    this I would maintain is the CUSTOMERS problem NOT DIGITALS/IBM/HP/etc.
    
    
    If the people who manage/maintain/upgrade systems would somehow
    get the information on "known bugs" to the people who write the
    software that might cure about 75% of the problems....
    
    How many of us have written a piece of software, tested it, released
    it and had the user find something we didn't in the testing?? When
    the problem is researched we often find it was a known problem that
    was documented(stars/release notes/etc) but 90% of FAIL TO RTFM until
    after the fact...IT's TOO LATE THEN AND EASY TO BLAME IT ON
    DIGITAL/IBM/HP/ect....
    
    excuse the flames but sometimes the customer/user has to take some
    responsibility also...

Things must be going downhill.

Remember when there was a publication called "software dispatch"?  Its purpose
was to describe all the problems for which there were patches, all the problems
for which there weren't patches but were workarounds.  For a long time it
even contained the patches itself.

	paul

    re: .27
    
    >>> When the problem is researched we often find it was a known problem
    >>> that was documented(stars/release notes/etc) but 90% of FAIL TO RTFM
    >>> until after the fact...IT's TOO LATE THEN AND EASY TO BLAME IT ON
    >>> DIGITAL/IBM/HP/ect....
    
    But this is exactly the point -- the customers *often don't have access
    to this information until after the fact.*  They can't RTFM because
    there is no FM to R.  And then half the time we want to charge them
    more to give them the FM they wanted in the first place that would have
    prevented the problem for everybody. 
    
    --bonnie, former CSSE

    now many products' release notes are bigger than the Software Dispatch
    ever was.
    
    ed

Oh by the way, re "what do other companies do" -- Microsoft has a big
database (looks like a complete database) of problem reports, workarounds,
etc., online for anyone to read.  Look on ftp.microsoft.com, look for
directories named "KB" (knowledge base).

	paul

    
    
    to be fair, there is now an ftp site at the CSC here in colorado springs
    that offers pull access to ultrix patches.  i think it may actually
    be all of the patches resident in CSCPAT...which would include
    VMS-related patches, as well.  the whoops that that two guys that set
    this up had to jump through, though, are a great example of the old
    thinking on patch distribution.  while this solution is not
    specifically proactive, at least customers now have a tool that will
    enable them to be proactive.
    
    mark
    

    I started in "Support". This conversation is at least 17 years old.
    I did not see an argument: While the Customer is experiencing the
    problem, you can not go on testing the patch forever.
    
    The best try to get quality patches and in the order the Field needed
    them was VMS Engineering setting up a seperate maintenance group with
    CSSE management closely involved. There even were some Services
    people in that group. A few good ones decided to join Engineering.
    
    The best try to install patches proactively was the CTS-300 V4 patch
    batch job. It came monthly, together with the Dispatch, on a floppy 
    and Field people were asked to spread it. Airmail was a bit slow and
    copying these things 40 times a bit long, but it was worth it.
    
    We just get in trouble faster these days, I suppose.
    
    Al
      

>Remember when there was a publication called "software dispatch"?  Its purpose
>was to describe all the problems for which there were patches, all the problems
>for which there weren't patches but were workarounds.  For a long time it
>even contained the patches itself.

Ah, next thing you'll be wanting to ship autopatch tapes to
all customers...

---

> Ah, next thing you'll be wanting to ship autopatch tapes to
> all customers...

On 1600BPI 9-track magtape

(I, too, remember entering patches - by hand - from Software Dispatch. Autopatch
tape! what luxury!)

I also remember Autopatch. [It was a mechanism used to distribute collected,
tested patches to DECsystem-10/DECSYSTEM-20 customers.]  It was not exactly the
easiest thing to use.

However, it _did_ get bunches of patches out into the field in a relatively
timely manner.  Sometimes we met our goal of four a year; sometimes we slipped. 
But the point was that we believed the collected fruit of our debugging labor
belonged in our CUSTOMERS' hands, not just spinning around on the RP06s on
KL1026 or GIDNEY [our development systems].


And we also had the Software Dispatch, where we distributed either binary or
source patches to customer problems.  I received these all the time while a
customer.  When I came inside, I wrote several of them.  You got very conscious
of your writing when you knew a large audience of system programmers would be
reading on paper what you wrote for the answers...

And we also had the CMCO/CTCO mailings (Confidential Monitor Change
Order/Confidential TOPS-20 Change Order) for security-sensitive bug fixes. 
These went to a different list than the regular Dispatches -- usually the info
systems manager or computer center director -- because of their sensitive nature.

But the fixes went out.  To everyone.  No questions.


John

    You spend the big bucks for DSNlink and you have access to the patches
    as quickly as they are released.  It isn't available to all customers,
    just the VMS/ULTRIX/OSF customers.

    
    Hi,
    
    One idea our group is playing around with is this.
    
    We have a patch and send it to a customer once the customer accepts the
    solution and after a bit of time to find anything it's broken the patch 
    will then get put into a rolling up patch kit.  Each month/2 months we'll
    ship a properly validated kit rolled up patch kit and make it generally
    available.
    
    Mike

    re: .30
    
    not having the manuals is not a problem with the patch system...
    
    as I read .0 again it seems that whoever answered the customer was
    unaware of v2.1 release notes that DO CONTAIN a list of patches..
    
    that also is not a problem with the patch system...
    
    

    re: .40
    
    I would disagree -- if there is a list of patches and either the
    customer or the customer support people to whom the customer turned did
    not know about the patch list, then it is a problem with the patch
    system. 
    
    Since the base note is talking about v2, it's not clear that a v2.1
    patch list would do them any good anyway.
    
    --bonnie

>    not having the manuals is not a problem with the patch system...
>    
>    as I read .0 again it seems that whoever answered the customer was
>    unaware of v2.1 release notes that DO CONTAIN a list of patches..
>    
>    that also is not a problem with the patch system...

Yes indeed, our patch system is perfect!   So .0, you just go right back to 
that customer and tell them how wrong they are, and if they want to do 
business with us, they had better learn to use the perfected mechanisms that 
we have available for them, even if it doesn't meet there needs.

The nerve of some customers.

(Flush!)

    re: .38
    
    >You spend the big bucks for DSNlink
    
    DSNlink is free to support customers

>    re: .38
>    
>    >You spend the big bucks for DSNlink
>    
>    DSNlink is free to support customers

Gasoline is free to people who buy a $500,000 Ford Taurus from Exxon, too.

Can I interest you in a bridge?

Bob

    re: .41
    
    > or the customer support people to whom the customer turned
    
    BINGO...!!
    
    re: .42
    
    > Yes indeed, our patch system is perfect!
    
    no one ever said that...
    
    .0 can only use the system in place and if it's broke it ain't gonna
    get fixed whinning about it in notes files...

I just ran across a URL for Sun patches:

	ftp://sunsolve1.sun.com/pub/patches/patches.html

/harley

    re: .46
    
    but be very careful when using as .26 is correct in the hidden
    possibilities...

I have to agree with .26 that installing all patches blindly is a stupid
move, BUT it seems to me that hiding all the patches from a customer until
they ask isn't any more intelligent.

The old DEC motto of 'we know what's best for you, and we are going to
keep you from shooting yourself in the foot, even if you hate us for it'
isn't the way to handle customers either.

I don't believe customer's want to be told they aren't smart enough to
do the right thing - I know many of them aren't, but most of them don't
want to be told anyway.

Wouldn't it be better to make the patch information easily accessable,
with appropriatly attached warnings?  Then when a customer comes in with
a bleeding foot, you can tell them you warned them... (i.e. 'I told you
so' is a better approach than 'I won't tell you')??

	Joe

check out the URL for digital patches:

http://www.service.digital.com/home-g.html

click on the 'patch service' icon

mark

        I don't see the problem.  DEC STD 204 patch information is
        available to customers and Digital employees, all over the world. 
        Customers have the ability to access the information from more
        than one source.  Each patch clearly defines the "known problems"
        that it resolves.
        
        If this customer had stated that a list of "known problems" was not
        available, I would have a lot of sympathy.  This covers a lot of
        ground.  Compiling a list like this can be done.  I've even
        attempted to do this.  As a Support Center specialist myself, I
        struggled a long time, with this concept, before I realized the
        number of nuisance calls these lists were generating.  I still see
        value in producing the lists, they just should not be made customer
        viewable without a lot of customer education, maybe through DECUS.
        
        Dave Zaniewski

    If the information is available, but customers aren't generally aware
    of it, then the answer is simple: Make the information *more*
    available.
    
    I personally prefer the solution of reducing defects in products
    shipped by more careful design and manufacture, and an accurate
    accounting of the costs of non-quality (fielding and diagnosing support
    calls; developing, testing, and distributing patches; creating and
    distributing point releases).  All of those costs can be reduced, with
    the savings going directly to the bottom line.  I'm sure that if you
    knew what it was costing you it would take your breath away.

    re: .51
    
    When I was in CSSE, this was my job -- I was a software serviceability
    engineer.  I was supposed to get involved in projects early on and
    point out things that that were going to cause field and support
    problems.  I spent most of my time just trying to generate complete
    known-problem lists for the telephone support people, so they wouldn't
    get blindsided by the new releases.  This sort of up-front early-on
    work was one of the first things to go when life started getting rough.  
    We were still called serviceability engineers, but we were working on
    "engineering" "service delivery" "processes," which as near as I could
    figure out meant we were supposed to figure out how to get the
    customers to pay more money to get their problems fixed, instead of
    figuring out how to prevent problems in the first place.  
    
    Since leaving Digital, I've tried to get contracts for serviceability
    reports and first-user testing, but very few companies want to hear
    about problems up front.  I lost one contract specifically because the
    sample in the proposal showed I was going to be "too thorough" and
    cause engineers to "waste time fixing bugs before shipment."  They did
    not buy my argument that spending time now was going to save them money
    in the long run.  
    
    I guess it's the old "ounce of prevention beats a pound of cure" -- the
    ounce of prevention is really out of style right now. 
    
    --bonnie

    re: .52
    
    I agree this is the best way to go and it seems that as MONEY
    has become the driving factor many companies would rather "get it to
    market NOW" then try fixing peoblems later....
    
    It's sorry to see that alot of these companies with this approach
    are eating OUR lunch as they create the market for their product
    even when it doesn't work exactly as advertised....
    
    MAYBE THERE IS A LESSON HERE FOR US...
    
    					  it's a cut-throat business we're
    					  in so let's start playing
    					  hardball if we want to survive..

    let us remember, one of the reasons Crysler was losing money in the
    70's was because they were 'beta testing" design features on all
    customer's instead of debugging up front.  

    
    
    re .45
    
    
    >Whinning about it in notesfiles?
    
    excuse me? Have you ever tried to get anything FIXED in this company? 
    I've spend HOURS AND HOURS AND DAYS AND DAYS trying to get problems 
    resolved in this company. I've called VPs, I've sent letters to VPS and
    the President. I've jumped thru hoops trying to get even the simplest
    most logical things addressed. 
    I can't remember having affected ONE STINKING THING. 
    The closest I came was in working with Don Zereski on the fact that we
    are supporting prouducts without minute 1 of training, and getting
    killed by customers. He was fired(or TFSOd?_ before the problem was addressed...
    the training people I was working with were TFSOd. These SUPPORT
    specialists still have NO training on the product they SPECIALIZE in. 
    ....
    
    I usually bring these problems up in notesfiles after being frustrated
    AGAIN by my inability to make any progress towards a resolution, hoping
    that someone who CARES and who has more power than I do will read it
    and come up with some ideas .....
    
    Either no one cares any more, or NO ONE has any 'power' ...
    
    
    

Can't see how you can make the statement about not being trained.  

Eleven years at DEC now and have never had a problem getting the 
training needed to be competent in the job.  Always just got into
VTX LEARNING, look for the course I needed, registered, and went
there.  Then there's the option of just ordering the SPI (self-paced
instructions) and doing it in the office.

Have been prettly deliquent in my professional career - just took
DEC VMS and UNIX courses.  Laterly I've taken the necessary Microsoft
and Novell courses to keep my expertise current so that if DEC TFSO's
me I' confident that I'll be able to survive in the current market.

    Re -.1
    
    Maybe you are not included in the NO TRAINING gestapo message.
    
    We have a difficult time looking in VTX for courses on Printers, 
    H-P and TI do not list there, and Output Technology Corporation,
    Data Products, Printronix do not advertise there.  Try finding a
    listing on Fujitsu or Genicom printer Training.  
    
    IF YOU are looking for standard training, then maybe, just maybe you
    can get it, but when it comes to vendor printers, it is just not there,
    and you do not get it!
    
    Dave

	re: .56 

	I'll answer that lest Cathy be forced to climb through the tube and strangle you. :-) :-)

	Don't EVER make assumptions about how easy/possible it is to get training/equipment/ 
whatever for another group based on your situation.

	For those of us who don't live in the Greater Maynard area training = travel.
Travel is damned near impossible nowadays. 

	For those of us who support these products at the Customer Support Center.  We need 
training *before* the product ships.  (i.e. the courses are not available yet when we need 
them.)  

	For those of us supposed to be the last word before it heads up for Engineering to 
look at (interupting their development cycle), the training we need is *not* usage training, 
but in depth and internals level.   Those courses generally don't *ever* exist for most products.

	Self paced training???  It is to laugh!  The way we've been downsized and shuffled
around here, it's a bloody miracle when we get a chance to LOOK at pre-release software much 
less spend significant time on it.  

	Not to mention that there are severe limits to how many people can be out at one time, 
since the customers can't seem to schedule their problems around our training.

	Speaking as someone who supports two products that run on ALPHA PC's without an AXP 
in sight.... (AXP, Hell, I haven't seen a post-it note in ages!)

Tracey 
US CSC

            <<< Note 3269.58 by VMSNET::HEFFEL "Vini, vidi, visa" >>>

	re: .56 

I'll answer that lest Cathy be forced to climb through the tube and strangle
you. :-) :-)

Don't EVER make assumptions about how easy/possible it is to get
training/equipment/  whatever for another group based on your situation.

For those of us who don't live in the Greater Maynard area training = travel.
Travel is damned near impossible nowadays. 

For those of us who support these products at the Customer Support Center.  We
need  training *before* the product ships.  (i.e. the courses are not
available yet when we need  them.)  

For those of us supposed to be the last word before it heads up for
Engineering to  look at (interupting their development cycle), the training we
need is *not* usage training,  but in depth and internals level.   Those
courses generally don't *ever* exist for most products.

Self paced training???  It is to laugh!  The way we've been downsized and
shuffled around here, it's a bloody miracle when we get a chance to LOOK at
pre-release software much  less spend significant time on it.  

Not to mention that there are severe limits to how many people can be out at
one time,  since the customers can't seem to schedule their problems around
our training.

Speaking as someone who supports two products that run on ALPHA PC's without
an AXP  in sight.... (AXP, Hell, I haven't seen a post-it note in ages!)

Tracey 
US CSC

If you're that damn unhappy than I suggest that you re-train yourselves
and get a life in another position that will appreciate you talents.

    re -1.
    
    Best of luck to you when the New Digital comes knocking.
    
    bk

    If a worker needs some specific training to do a job, then
    management is responsible for either (A) hiring employees who have
    had it or (B) providing it.
    
    Any other way of doing business is chaotic.
    
    Any questions?

    Hail Eris!!!
    
    Our new motto?

    All hail Discordia! 
    
    Dick

    
    
    re .56
    
    
    >Eleven years at DEC now and have never had a problem getting the
    >training needed to be competent in the job.  Always just got into
    >VTX LEARNING, look for the course I needed, registered, and went
    >there.  Then there's the option of just ordering the SPI (self-paced
    >instructions) and doing it in the office.
    
    Geez, if I was so expendable, I'd sure be worried about my job. 
    
    
    Oh, on the SPI, do let me know when you find the one for UCX internals.
    Or the one for X25 on OSF. 
    Or the X500 one. 
    Or the POSIX one. 
    
    As for 'going there'...you must be joking. I was talking with a friend
    in Hull, PQ about the possibility of me going up there to teach a class
    that they desperatly need. I couldn't get approval to travel....
    
    But, I didn't bring up the training issue except to point out the fact
    that I have gone to great lengths to try and get things resolved. 
    I've come close to resolving some of the issues, but never got past the
    point of folks being TFSOd just when we got >that close< to a fix....
    
    So where is you work at anyways where training is so easy to come by?
    
    
    
    

    I just drive to the DEC training facility in El Segundo, California, 50
    miles from the Irvine facility.

    It appears that you are from the Colorado Support Center?  We'll that's
    the problem. They have the mushroom management philosophy:  Keep you in 
    the dark and expect you to grow.  We'll you're suppose to keep them in
    the dark and watch them get canned.  Hard to do sometimes...

    We had two individuals that came from the CSC way back - Steph Spooner
    and Marc Menniti.  I've heard all the horror stories - no training and
    works you okolis off.  We'll do what Steph and Marc - re-training and
    get out.  Easier said than done.

    You appear to be pretty unhappy but I guess not unhappy enough to
    leave.  The problem with the CSC management, which goes back to the
    Peter Zeek days, if my memories servers me, is that they don't believe 
    in investing in their people.  The CSC management fell that you are 
    disposable - if you don't want to do it they'll just get some other
    individual that will and for peanuts.
    
    When they attempted to close the CSC support line for the Business
    Partners, I believe that management was overwhelmed with complaints.  I
    thought they would have woke up and smelled the coffee and recognize
    the need for quality support for our products.  I guess not because
    they'd goaled on profit not customer satifaction.  If they don't train
    you and you get the job done they look that much better.  I wonder if
    they use this philosophy on their own kids.  Every time I've asked this
    in the past they just looked at me dumb-founded.

    Re.56, .58, .66
    
    	In my 21 years in DIGITAL, I have never seen such arrogance in a
    Conference, as yours TENNIS::KAM!!!!!
    
    	You are obviously in the minority, yet you seem to think you are in
    the majority and slate the rest of us because we are unable to get
    training to do our job.
    
    	I work in Pre-Sales Tech. Support and very often, am called upon to
    answer questions on options that I didn't even know existed, much less
    that they had been announced.  I'm not asking for pity - but for you to
    realise just how lucky you obviously are in your situation.
    
    	I hope that you manage to keep your job - DIGITAL needs trained
    people!!!!
    
    				Malcolm.

    RE:3269.67
    
    Having come to the CSC from outside four years ago, I think .66 hit it
    on the nose. He does come across as arrogant, and I really wasn't with
    him until his last message, but he's made a fine assessment of the
    situation.
    
    This organization is goaled on profit only and doesn't really care so
    much about quality. 

>    If a worker needs some specific training to do a job, then
>    management is responsible for either (A) hiring employees who have
>    had it or (B) providing it.
    
	Ah ha!  Finally the operative point in question comes out.


	Responsible management!

    re: .56
    
    It's about time that people in the digital PUZZLE PALACE stop
    and smell the roses.  The field has TFSO'd EVERY INSTRUCTOR 
    with the exception of THREE, AND THEY DON'T TEACH! They
    are on Retainer by the management to have a core competency! But
    again........THEY DONT TEACH!  MCS management has problems locating their
    butts when it's near a hole in the ground in most cases. And the
    training issue is a REAL ONE.  I'm working on a program called the
    VIDEO SERVER project.....and the MCS management attitude is that it's
    all off the shelf stuff, and we DON'T NEED TO TRAIN ANYONE FROM THE
    FIELD!  Tell that to the folks that are gonna look pretty dumb to
    a customer that just paid eleven million for a system, it's broke
    and NO ONE from the field has ever seen one!   Pretty scarey! 
    
    The field people have enough problems getting their jobs done with
    the little resources they actually have. Let's not really piss them
    off with such stupid remarks!  
    
    chet

     
    And to further deepen and widen this rathole...
    
    Training in our office isn't THAT big a deal, it's mentioned once in a
    while, but to actually GO requires major scheduling. Vacations? right.
    I supposedly get 4 weeks per year (17+ years), but I haven't had the
    ability to schedule any for while now, there are too many special
    projects going on, too many "drop what your doing and go fix this
    special deal gizmo" type calls, too much of too many things.
    
    I used to do it for me, becuase I liked it, then I started to do it for
    the customers, to protect them from digital, now I just do it.
    
    .mike.

Common Name:   BILL KAM
Search Surname:  KAM  Search Given Name:  BILL,  WILLIAM,
WILLIAM STANLEY LAI  DTN:  535-4133  Telephone:  Office: 714.261.4133,
FAX: 714.261.4303,  BBS: 714.476.8136  Intrnl Mail Addr:  IVO2  Location:  IVO
Node:  tennis::kam  Org Unit:  WW SALES HQ,  World-wide Sales Training
Position:  Strategic Training & Support Mgr

        KAM,
    	A few times you stated that we seem unhappy, implying that we
    should leave.  Many of us hope these problems will be resolved, and
    have invested much time and effort to correct these problems.  Many
    have left, many will leave.  Still! I consider your attitude part of
    the problem.  An attitude of: If you don't like it go somewhere else.
    Note 73, says you are a manager.  If so, you typify the current
    management that has caused this company to crumble.  A good manager
    would have tried to help correct the problems, rather than hold to the
    problems and get rid of those really working for the betterment of this
    company.  As for your so called training...  You try and support people
    to the internal level with whatever training you've had in the past
    5 years.  Come on over to my phone, and LETS SEE HOW GOOD YOU FEEL. 
    And yes, that's a challenge...

    Jim Morton
    Remote Support
    Colorado Springs

        If .73 is true, why is a manager wasting company time and money
        taking technical training?  
        
        I'd offer the same challenge as Jim!  I'm currently trying to
        reskill myself as a result of a reassignment, and I don't live
        within 500 miles of a training facility.
        
        Dave Zaniewski
        Alpharetta CSC

    I Would like to see TENNIS::KAM go to a customer site and try to fix
    something he has never seen or heard about, that takes special tools
    to get into, and if you "break into" it, leaves it virutally
    inoperable.  It happens!!
    
    Or there is the old story " I wen tot the customer site and was leaning
    against some machine and ask where is the xyz system? and the customer
    says you're leaning against it"!  This has even happend to me when I
    was a hardware FE 6-7 years ago!
    
    BTW,  I will be leaving, as I was one of the lucky ~250 people involved
    in the RDB sale to Oracle.  I did get internal level training for RDB,
    but you should have seen how long it took.
    
    
    Mike Austin
    RDB Support