Conference 7.286::digital

I wonder what the *real* reason is for their replacing Digital equipment with
IBM.  I doubt a company would change their computing strategy on such a rumor
without checking it out first.

Paul

    .0 that we're "not expected to be around much longer." 
    
    Sounds like the BLM type was brainwashed by a IBM type and by the
    way - the sky is falling, the sky is falling...

    What or Who is "BLM?"

    Bureau of Land Management - tends to all the federal land we own.
    (my guess, since .0 referred to it as 'the bureau').

    According to my records, the one 6400 has been returned and they no
    longer have the equipment at there Denver Site.,

BLM is the Bureau of Land Management, a government agency, along 
with National Park Service and Bureau of Indian Affairs, under 
the Department of the Interior.

re Note 2846.0 by NWD002::SCHWENKEN_FR:

> The 
> reason given is that we're "not expected to be around much 
> longer." 

        Look -- Digital has been changing a lot lately and has
        dropped some products and is likely to drop more as we "find
        ourselves."

        For the customer who has become dependent upon a particular
        product or service, once we drop that product or service,
        we're no longer in business.

        Digital doesn't have to be at risk for going out of business
        completely for this perception to be valid.

        Bob

    Yeah ... IBM is really doing great with the Feds these days. They're
    doing so well they couldn't wait to get rid of their Federal Systems
    Unit. Any gov't bureau that does too much single sourcing today is
    running the risk of a GAO investigation.

    As soon as IBM & DEC (excuse me, digital) merge, we'll be back at BLM.

    I know of Customer that are switch from DG Aviion to Alpha, because of
    the state of DG, and the lack of future in the Motorola (88100 chip in
    aviion) product set...
    
    OF course, if we were smart we could capitalize on this but...
    
    q
    

    So tell them not to worry, because we've got a better life expectancy
    than the current administration.

    Depending on his politics, either he'll laugh, or invite you to leave
    permanently (no great loss, judging by .5)

    Dick

    Re: last few
    
    You have missed entirely the premise of the base note!  He has had more
    than one customer indicate concern about the entire viability of
    Digital.  It is real, and I have encountered it myself.  You shouldn't
    scoff at it.  It is a very difficult objection to deal with.  Remember
    the BUNCH?  (For those who don't: Burroughs, Univac, NCR, Control Data,
    Honeywell)  Many organizations went through the transition from
    customers of the Bunch, to customers of someone else.  It can/will happen
    again.                                                            

    I think that the foundation of these rumours lies in the end of life
    for DECnet Phase IV.  The sentiment that I've heard echoed in countless
    trade rags is that many customers who are forced to transition from
    DECnet Phase IV to Phase V will opt to do away with their DEC equipment
    altogether in favor of TCP/IP.  Most of our customers are very happy
    with DECnet Phase IV and don't want to deal with the expense of
    transitioning their networks to Phase V.  For customers whose DECnet
    implementations constitute a lesser percentage of their installed
    network base, it is less costly to oust DECnet altogether in favor of
    TCP/IP.
    
    I think that this note string would be more appropriately titled "Kiss
    of Death for DECnet".
    
    Ken

I agree with .13.   There isn't a single customer in my geography that is 
planning to transition to Phase V.   They are all moving to TCP/IP, and no,
they are not buying ours.   All of them would continue happily along with 
DECnet Phase IV if they could, including purchasing it one new processors, 
and purchasing Digital processors specifically because they have DECnet.

The network partners have voiced their concerns to Networks Engineering,
but to no avail.

Bob

    I believe you'll see most internal organizations ignore phase v
    and go directly to TCP/IP. In some instances it has already begun.
    
    Jim C.
    
    

    If BLM were to have access to this note and its replies, it
    would feel perfectly justified in moving off of Digital to
    IBM.
    
    We used to say "Think Customer".  We ought to be following
    "Think LIKE A Customer".  If we did, we would not be FORCING
    customers away from that which they are comfortable with.
    
    

I think what we should be telling customers is that a move from DECnet Phase IV
to DECnet/OSI is not a big deal, at least for most customers.

Paul

	There are a few points that DECnet users need to understand
	with regard to upgrading their VMS system's to DECnet-OSI for
	Open VMS from PhaseIV.

	When upgrading End Nodes on your network, you do not have to 
	upgrade all your routers.  PhaseV End Nodes are capable of 
	existing on a PhaseIV backbone, (running Distance Vector).
	At some time in the future, if you need the additional addressing
	space or wish to communicate with another vendor over OSI CLNS,
	your End Nodes will work in this environment as well.

	The PhaseIV application interface, ($QIO), is preserved in PhaseV.
	Thus, if you've written applications to run over DECnet, they should
	run without recompilation on a PhaseV end node.

	If you are not interested in a DECDNS distributed namespace to
	manage node names, a Local name space option is shipped that will
	be populated from your PhaseIV name space at configuration time.
	You may manage up to 150 nodes using the local name space option.
	(If your network contains 250, you could pick and choose the nodes
	you wish.)

	The current releases have made strides in the ease of configuration
	catagory especially for those customers who want to use local naming
	in much the same manor their PhaseIV node was configured.

	While it is true that the kit is very large, unless you need or
	use the OSI applications, DNS server, PSI software, DTSS server, or
	other optional software, these pieces are not installed.  Alot of
	our customers do want this software and it is provided as a single
	kit on their behalf.

	I hope these points help apprehensions that people might have about
	upgrading their PhaseIV VMS nodes to PhaseV.

	Regards,

	Pete Carson
	DECnet-OSI Engineering

    re: 18,
    
    Pete, you didn't mention those products that also use NCP, in addition
    to $QIO. 
    
    Isn't there now a utility that can be run to translate NCP commands
    into NCL? 
    
    John
    

It sure looks like we need to do a better job of getting that message out.
Here are some excerpts from the DECUServe discussion of this subject.
It goes on like this for about 80 notes so far.


> VMS is a dead issue at my site. Only the legacy stuff is still on VMS, and
>most of that will be dead in 19 months. Every time I start thinking about
>going to V6.0, some new stupidity comes along - first it was the fact that
>I need the DSV11 sync driver, but the WANDD V1.1 kit won't work on V6.0, so
>I have to wait for (and buy) all of DECnet/OSI to get the driver. Now it's
>DECnet Phase IV, where I would have no upgrade path after going to 6.1, which
>would likely be the first V6 I could run (because of the WANDD problem).

>    I'm already looking at extra expense converting the TCP/IP link from a
>    bunch of radio terminals we're about to buy, to LAT.  OSI is a scary
>    proposition for my company, which will gain us absolutely nothing.  I
>    can sympathize with Digital on the funding thing, but it sure looks
>    like they're doing their best to drive us to a 3rd-party network
>    vendor.

>Personally I don't see why DEC should mandate that its customers migrate to
>Phase V just because the Easynet has grown too large for Phase IV.  Hey, maybe
>they could replace all the workstations on DECfolks' desks with terminals to
>departmental VMS systems -- that'll get the node count down!

>    Well, actually, I see it as Digital giving us another reason to write
>    them off -- another thinly disguised attempt to screw their long-time
>    VMS customers (and some of their biggest supporters).  After I read the
>    original note describing this, I sent my boss a recommendation that we
>    begin serious planning to move away from VMS and Digital (since Digital
>    has left us no other choice).  And if you know me, you know that I'm
>    pro-VMS almost to the point of irrationality :-)  But many of us have
>    finally become really fed up with Digital constantly sticking it to us.

>    Ditto, almost. This isn't going to cost me money - I assume I'll get
>    OSI/Phase V at no incremental cost under the CSLG. What it adds to,
>    though, is the hassle factor. I don't want Phase V. I don't need
>    Decnet. I don't want to even think about these issues. I don't
>    have the time to worry about what a forced migration to Phase V
>    will mean for what little use we make of Decnet, nor do I want
>    to spend time on whether or not a Decnet-less cluster is possible
>    (likely) or supported (not likely).
 
>The only reason we have not installed VMS 6.0 is because PSI and the WAN
>device drivers are not supported under VMS 6.0 EXCEPT as part as DECnet
>OSI.  Phase V offers us NOTHING except a bigger hassle to configure and
>manage.

>TCP/IP won the protocol wars as far as we're concerned (eg, we're spending
>$$$ on TCP/IP packages (not Dec's, we figure with the competition they'll
>bow out of the TCP/IP arena soon)) and OSI buys us nothing.

> The only reason DEC isn't hearing more screaming now is that folks are seeing
> that they have options other than sticking with DEC.
 
>    What's probably going to happen here is that if we have to pay for
>    DECnet Phase V, we won't: we will pay somebody other than Digital for
>    TCP/IP, even though DECnet is a lot more 'seamless' at the moment.

>DEC seems determined to continue to ingore their customers and charge ahead
>with ramming this turkey down our throats.  I've been dreading the day since
>1987 when I got a copy of "DECnet DIGITAL Network Architecture (Phase V)
>General Description", EK-DNAPV-GD, September 1987.  Yes, thats nineteen eighty
>seven - nearly 7 years ago.
 
> The version that kills DECnet Phase IV and requires OSI is the version
>that will kill VMS for my company.  Sad but true...we've had a long, happy
>relationship with DEC and VMS, but I'm afraid that DEC is shooting themselves
>in the foot with this one.  Over the last decade, we have been consistently
>one of DEC's top 10 customers (often one of the top 3 non-military) and I
>think this year we dropped to about #20...partly due to availability of good
>products from competitors, but mostly due to the decommitment of products and
>costly migration paths of new ones.

>    Isn't there now a utility that can be run to translate NCP commands
>    into NCL? 

	DECNET_MIGRATE CONVERT COMMAND will convert an NCP command into
	an NCL command and display it for you.  NCP will now attempt
	to convert the command to NCL and execute it.
 

> we must not be telling customers then

	We need to do much better!   We had a journalist in a DECUS
	workshop we had on this in SF and immediately after he still wrote
	an article indicating that you need to migrate all your routers
	and set up a name space.

RE: .18 (Pete Carson)

Pete, you make some valid points, but I believe they miss the mark in some
major ways.

You say:

>	When upgrading End Nodes on your network, you do not have to 
>	upgrade all your routers.  

A good point, but consider the number of routers as compared to the number
of end nodes.  You are saying that when a customer upgrades 100 nodes, he
can let 5 of them (the routers) stay at Phase IV.  This "savings" is so
small when compared to the amount of work required that it is lost in the
schedule.  Therefore, this point is meaningless to most customers.

>	The PhaseIV application interface, ($QIO), is preserved in PhaseV.
>	Thus, if you've written applications to run over DECnet, they should
>	run without recompilation on a PhaseV end node.

Excellent design, and a good thought in preserving our customers investment
in their tools.  But you say "should run".  What level of testing with
selected customers applications has/will be done to ensure this?  What
services are we offering to assist our customers application migration?

>	You may manage up to 150 nodes using the local name space option.
>	(If your network contains 250, you could pick and choose the nodes
>	you wish.)

150 nodes is *way* too small for most of the customers I see.  And what
implications are there for the 100 nodes which were left out?

>	I hope these points help apprehensions that people might have about
>	upgrading their PhaseIV VMS nodes to PhaseV.

Unfortunately not, Pete.  It seems to me that a customer system manager will
have to install a large kit (of which only sub-sets are actually installed)
on almost every node on their huge network, for no benefit whatever.  Their
performance will not improve dramatically, the functionality of their current 
applications will not change, and they will not see revolutionary new uses 
for their Phase V network over that of their Phase IV network.  (I am not 
saying that there are not revolutionary differences in the *internals* of 
the network;  I am talking about the perceptions of the customer who does 
not understand those internals).

My final point is, as a Sales Support person who is expected to be able to
tell customers why they should spend time and money on Digital products as
opposed to third party products, what do I tell customers when they ask me
about Phase V?  And more important, what do I tell them when they ask me
when the Digital Easynet will be completely cut over to Phase V, and how
long it took to do it, and what problems we encountered doing it?  As far
as I know, there are no plans to completely convert the Easynet to Phase V,
so I look pretty foolish recommending that customers do something that we 
are not going to do.

-- Ken Moreau

    
    And just to pick on Pete and Paul a little more;
    
    The comment that "alot of our customers want this software" left me
    scratching my head. I do telephone support and talk to 10 to 30 
    customers a day, from huge dp shops to the mom 'n pop operations.
    My experience has been that less than 1 percent of the customers I 
    talk to are interested in Phase V. In fact, not only are they not 
    interested, but are resentful and in some cases angry about how this
    is being handled. The comments I hear are very much like the ones 
    .20 posted from DECUServe. 
    
    Neil

re Note 2846.23 by CSC32::N_WALLACE:

>     The comments I hear are very much like the ones 
>     .20 posted from DECUServe. 
  
        I know that it's all too easy to say this in retrospect, but
        this whole DECnet Phase V/OSI thing was a LARGE mistake.

        Back when this ball was getting rolling (which seemed like
        five or more years ago, right?) we believed, and were telling
        the world, that OSI-based protocols were going to be
        replacing both DECnet and TCP/IP.

        Well, it didn't happen that way.  Mistakes happen -- it was
        the honest kind of mistake that pioneers make sometimes.  The
        biggest inexcusable mistake was that we didn't have a
        fall-back strategy, especially when it became apparent (as it
        has been for years) that TCP/IP was NOT going away but
        instead was becoming more dominant.

        As my former boss was fond of saying, you need "fast
        failures".  It's slow failures like this that really kill
        you.

        Bob

    We're really migrated from the orignal topic which is do customers
    not want to buy from us due to the fact they believe we will go
    under at some point.  To those interested in that, sorry about this
    tangent.
    
    .22
    
    My point about the routers was that customers are apprehensive
    about having to spend $ to replace their routers with those supporting
    PhaseV.  Upgrading each end node was not an issue once we demonstrated
    an installation and configuration at the campground at DECUS.  The
    5.6/5.7 release will ask a customer the following during configuration;
    	Do you want to convert your PhaseIV DB to PhaseV
    	What is your node name? 
    	What is your Synonym?
    	What is your PhaseIV address?
    	What is your IPD.
    
    Each of these is explained in detail.  Engineering is committed to 
    making this as easy as possible and removing barriers that keep 
    customers from migrating.  We need the field to carry this message
    and give us feedback as to what barriers exist.
    
    'should work' should read 'will work'.
    
    > Mom and Pop
    
    	I hear you.  Alot of the people who want this are in Europe or
    	in large international corporations.
    
    .23
    The key word here is slow.   While OSI was being hashed out by the 
    standards bodies, (we released based on some specs that were not
    final), TCPIP was given away FREE with UNIX.  We now have to deal with
    the cards that have been dealt to us.  To those customers
    we should sell a solution that works in a TCPIP environment.  We need
    to make our DECNET applications work in this environment and don't
    think we don't know this. 
    
    -Pete

Re:.25

>>  Upgrading each end node was not an issue once we demonstrated
>>  an installation and configuration at the campground at DECUS.  The
>>  5.6/5.7 release will ask a customer the following during configuration;
>>  	Do you want to convert your PhaseIV DB to PhaseV
>>  	What is your node name? 
>>  	What is your Synonym?
>>  	What is your PhaseIV address?
>>  	What is your IPD.
>>  
>>  Each of these is explained in detail.

Great.   But what isn't "explained in detail" is why I would WANT to do this,
for no significant benefit to my company or my users.

If I have several hundred production nodes to perform this task on, that's a 
six-month roll-out, and hundreds of thousands of dollars.

I'm sure Engineering has built a great product.   The Edsel was a great 
automobile.  The Rainbow was a great PC.

But once again, we are failing to LISTEN TO THE CUSTOMER!   We've put a very 
loyal installed base at risk, once again, by forcing yet another Rainbow on
them.

Sorry... but the customer controls the market in the 1990's, not the vendor.
And our customers don't want OSI.

Bob Deep
Network Partner
Syracuse, NY

Re: .25;
 PhaseV endnodes run with same license as PhaseIV

That's nice, but even if we give all aspects of PhaseV/OSI away FREE,
its going to cost customers some serious bucks to convert to OSI, in labor
and lost production costs alone not counting any hardware shuffling which
may ultimately be necessary to manage the new paradigm most efficiently
(I assume that phaseV isn't optimized to run in phase IV emulation mode).

If the majority of our customers see major additional cost and no perceivable
benefit, it will at least give them reason to evaluate alternatives like going
off Digital platforms/networks entirely.

We cannot afford to give our competitors advantages like this.

Maybe OSI should be packaged as a premium network option for customers who
really need the power and capability, but don't force customers to pay for their
loyalty.

Kevin

And no matter how you slice it, for the average customer, using NCL to try to do
identical functions to what NCP has been doing is like using a Space Shuttle to
fetch groceries from the corner store.

Read: COMPLEX to understand and use
Read: staff EXPENSE to implement

I expended a good deal of my personal credibility in the mid-late '80s pushing
the corporate message regarding Phase V. The more I learned, the more I touched
what there was to touch, the more delivery slipped, the more I became afraid for
the future we were pushing.

Not a word about technical/engineering elegance. Not the issue for my customers.
Netware and TCP/IP are not models of technical excellence - just marketing
superiority based on satisfying common needs inexpensively and not always well.

Norm

    
    This paints a sad picture ! Is the situation reversible ?
    
    peter
    
    

Re:.29

I don't know, but I extracted the comments from the customers and forwarded it
to the Network Partners for their input.   I plan to make this a topic of
discussion for Larry Walker at the Network Academy at the end of the month.

I view this as a serious situation that has to be resolved.

Bob

    I believe Digital is a very forward thinking company who will make it
    thru the tuff times.  It sounds like an IBM type or types have assumed
    leadership at this organization and they don't like Digital.   
    
    If that is true let's not stu in it but let's turn it around - WE
    have a excellent future.   
    
    
    
    

> Is the situation reversible ?

Depends on what you mean by "reversible".

If you're asking whether it's possible to get customers to see the
value of Phase V, there's not the slightest chance as long as there's
so much resistance *within* the company to DECnet-OSI, and maybe not
much better chance if everyone were solidly behind it.

If you're asking whether Digital can win customers by embracing IP in a
convincing way, I think this is possible, but it can't happen as long
as so few people in Digital use IP as their preferred transport.

As things stand at this moment, there's little prospect of either
"reversal", and that, very simply, spells the end of Digital as a
network vendor (well, maybe Pathworks will do ok ...). People in this
company act like they're glued to DECnet Phase IV, and, whichever way
you slice it, that's a goner.

    Just who needs OSI? 1 or 2 % of our customers? Why try to shove 
    it down customers throats when it just generates bad publicity 
    for us? I had hoped we had grown to the point where we realized
    that just because someone in Digital thinks an idea is good our
    customers make the final decisions. Their wants and needs is 
    what we should base our strategies on.
    
    TCP/IP is the choice of the masses for good or bad. TCP/UDP
    Bigger Addresses (TUBA) is a possibility to help the 1% of
    the customers that absolutely have to have more addressing. We
    will lose a lot more business by dropping support for Decnet
    Phase IV and mandating Phase V then we will ever gain by it.
    Put the customer first! Find out what they want and give it
    to them. It doesn't get any simplier then that.
    
    			-Jim-  Pulling my hair out again ;)

Oh, because of about many billions in sales in Asia and Europe

    OSI is not totally dead in Europe or Asia.  In fact the work going
    on in the Asia/Oceanic workshop (AOW) with multi-byte character
    sets suggests that it will live for some time yet.   It's my
    understanding that TCP/IP can't (as yet) handle the non-anglophone
    cultures too well.  Anyhow, the evolution of TCP/IP is under the
    direct control of the US (unlike ISO) and cultural racism may
    its growth limiting factor..
    
    Digital's main failure may have been in the US market.  Things are
    not quite so bad elsewhere.
    
    I remember from my CSSE days that 80% of customer networks had
    <=20 nodes and so didn't need Phase V, but our large customers
    were running out of addresses fast.....
    
    Methinks we weren't listening to the majority of our customers.
    
    Still, it's all too clear with 20/20 hindsight.  I wish I had the
    same clarity of vision for the next 5 years..
    
    -Dave.
    
    

    
    
    
      
    
    

    This debate over OSI certainly sounds like a US-centric debate. 
    Reminds me of the Network Partner meeting where all the US folks seemed
    anxious to kill the DECnis (OSI-centric router) and the few European
    folks in the crowd had to educate the largely North American crowd of
    realities outside the Western hemisphere (and where the majority of
    Digital's revenues come from).
    
    There is so much FUD generated WITHIN this company about DECnet/OSI
    that it's no wonder we see so much apprehension from our customers. 
    The reality is DECnet-IV's days are numbered as a product within
    Digital.  You may not like the situation, but this moaning, griping and
    second-guessing about DECnet is a waste of time.  Help your customer,
    educate them or migrate them to TCP/IP if it's the right decision. 
    Tree hugging ain't helping us here.

>    Reminds me of the Network Partner meeting where all the US folks seemed
>    anxious to kill the DECnis (OSI-centric router) and the few European
>    folks in the crowd had to educate the largely North American crowd of
>    realities outside the Western hemisphere (and where the majority of
>    Digital's revenues come from).

  Thanks for the shot of reality (and I spent almost five years in
  Europe)! I'm impressed that you *were* able to educate.

  Unfortunately, a lot of decisions get made by concensus, which is, to
  a large extent, an informal voting process. Elections which are
  one-person=one-vote where the majority of voters are US-based don't
  reflect the reality that the US is not Digital's largest market. There
  have been an awful lot of bad strategic decisions made that way, and
  the cost has been very high (e.g., in re-engineering products so that
  they can be sold in our largest markets).

  I have a sense that Palmer, and ultimately Strecker and Supnik,
  understand where our revenue comes from. Still, it's easy to imagine a
  roomfull of US-based folks sitting around, Europe and Asia not well
  represented, trying to persuade them to, say, cancel DECnet-OSI. Do
  they remember, under those circumstances, where the bread comes from?

  This is a good example of what a poor sample of reality notesfiles are
  (not to mention the fact that they're almost exclusively accessed by
  people using DECnet Phase IV on VMS). Darn good thing important
  decisions aren't based mainly on what gets recommended here. (I once
  observed that most of my friends could be reached via electronic mail,
  and suddenly felt very sad that I had somehow managed to limit my life
  to such a homogeneous community). You often see complaints in here
  that "they're not listening to us". Maybe it's us (participants in
  DIGITAL) who are not listening to much outside the community of
  typical noters.

  The replies in most notesfiles are written largely by:

  	US-based
  	VMS
  	DECnet Phase IV
  	Software types

  This doesn't resemble the profile of most customers, or even of most
  Digital employees. It's ironic that this notesfile is called
  "DIGITAL", not "DEC".

If the problem is with installing DECnet/OSI then why not just bundle the
non-server components with VMS V6.whatever?

Wasn't the whole Big Address problem part of our attempt to focus on Fortune
500 giant "enterprises"?  Where do we stand in this market anyhow and how
much more growth is there in it?  Judging by the new EuroVP's push back into
SME, somebody upstairs has decided it's time to stop ignoring smaller
customers.  I wonder how many of the current products would've been designed
the way they are if that had been the focus 5 years ago.

								- paul

Of course, no ome FORCED the customer base to buy the DECnis.  When we didn't
offer a product that met there needs, Cisco did, and they took us from a 
market in which we owned 95%, down to less than 10% (mostly legacy).

Cisco ships more units in a month than we shipped all of last year.

Did the DECnis make a profit?

Will DECnet/OSI make a profit?   

Or will it simply make the choice to move to TCP/IP easier for our loyal
customers.

DECnet Phase IV wasn't broke.  Dropping support for it in order to push 
an unwanted technology will not work, regardless of geography.  (Wasn't 
Europe supposed to be all OSI by 1992?)

Network Engineering, by dropping support for DECnet Phase IV, has simply 
choosen to abandon the US DECnet market.  On the last Larry Walker slide
I saw, that was about $180M per year.   

I wonder how many NEW DECnet/OSI customers do we need to pick up from Europe 
and APA to make up for that loss?

With a $180M revenue stream, couldn't we afford to invest a little of that
into migrating the software to newer versions of VMS?   Is it that expensive?

Bob

    The fundamental truth about networking market is that it is so big that
    it will support several technologies. Remember talks about computer
    business shake out few years ago, it did not happen. There are more
    computer companies today then ever and the same is true about networks.
    Almost every industry sees the trend, cost of entry goes down and
    specialisation pays off.

    There is always going to exist TCP, OSI, DECnet , Novel, Apple talk,
    LanManager and the rest. The trick is to make money in every market and
    it is possible. 

    We have sold several thousands DECnises, it is now best performing
    router on the market. We are now second router vendor .
    CISCO stops working ( massive packet losses ) under heavy load, they
    have problems to go beyond AGS+. CISCO chose not to participate in
    recent "Data Communication " performance test with the 7000.
     
    We have a very consistent networking product strategy with
    DEChubs, high performance routers and very high performance
    ATM/GigaSwitch. CISCO and the others are one product line company
    desperately looking for alliances in hub/switch/software/middleware
    world. There are some unpopular long term choices that we made years
    ago that now start paying off. Our networking products are generally
    better engineered, more reliable and higher performance then the
    market. I can't put growth rates for our products in here but trend is
    very encouraging.

    With more reality oriented marketing and advertising ( we are in
    "consumer" networking) , we could have seen even better figures.
    The advertising is more important then ever since our products can
    be sold into non-DEC content accounts.

    	And last "rumours about phase IV death are greatly exaggerated".

    						wlodek

Re: .41

I don't smoke anymore...

I agree that the DECnis is a better Bridge/Router than the Cisco AGS+ and
is on par with the 7000 for a lot less money.

I also know that in my geography, every Fortune 50 company has standardized 
on Cisco Routers.

We can't even sell the DECnis into Kodak, and Digital RUNS their network.

In my territory, there are hundreds of Cisco routers, and ONE DECnis!  (We
gave that one away as part of a research grant.)

As for DECnet Phase IV:

>> And last "rumours about phase IV death are greatly exaggerated".

If that's true, someone better tell us, and our customers.  Refer to the 
headline in the Dec 20th Network World "D-day near for DEC users."

"DEC users have their backs against the wall.   Digital Equipment Corp. will 
unbundle DECnet Phase IV from the OpenVMS operating systems in 1995, meaning
users will have to start migrating to DECnet/OSI [this] year, cease upgrading
their operating systems or ditch DECnet altogether.   OpenVMS version 6.1,
expected out [this] spring, will be the last release to include DECnet 
Phase IV."

If there is a different message, the Network Partner's haven't been told yet.

Bob

    .18
    
    	you miss the point....the customers DO NOT WANT TO UPGRADE
    	ANYTHING. peroid. they don't care about the newest wizbang.
    	they are comfortable and YOU, are forcing them to change.
    	well they have a cure for that, they will simply move to
    	another supplier that LISTENS to them instead OF DICTATING
    	to them.
    
    
    	we had better start listining to customers rather than
    	ourselves.
    
    
    	rth

re .43,

� you miss the point....the customers DO NOT WANT TO UPGRADE ANYTHING. peroid.
� they don't care about the newest wizbang.

Some customers do not want or need to upgrade software and do not care that
they miss out on new products or versions.  Others keep up with software
versions and don't need a sudden massive software upgrade to take advantage of
new software or hardware.  Neither one is "right" or "wrong" but I don't
believe one can make a blanket statement that "customers do not want to upgrade
anything".  It depends on the customer's business model and what problems they
need to solve.

� they are comfortable and YOU, are forcing them to change. well they have a
� cure for that, they will simply move to another supplier that LISTENS to them
� instead OF DICTATING to them.

Customers should be given the choice of upgrading or not.  Even if DECnet Phase
IV disappears from a future version of OpenVMS, no one is forcing the customer
to upgrade to that version.  No software, from Digital or anyone else, is
supported forever.

� we had better start listining to customers rather than ourselves.

Agreed.

Paul

Re:.44 (Paul)

>> Customers should be given the choice of upgrading or not.

Agreed!   That's exactly what I've been saying.  But then you add...

>> Even if DECnet Phase IV disappears from a future version of OpenVMS, no 
>> one is forcing the customer to upgrade to that version.  

But we are!   We're saying if you want to be current on the operating system,
and the latest layered products, then you have to change the way you run
your network... even if the new features you want are not network related 
in the least.  And that's the problem.

>> No software, from Digital or anyone else, is supported forever.

That's true if you're losing money on the software.   As far as I can tell,
DECnet is still very profitable... except for the OSI debacle... and there
are still thousands of customers out there who would pay for it on every
system they buy from us... But have told us quite bluntly that they will
not move to OSI.

Its our choice.  We can listen to the customer, or we can ignore them.
I choose to listen, and as a result I will tell everyone I can that forcing 
our customers to OSI is wrong.  They've told us so, the industry has told us 
so, every single protocol survey I've ever seen has told us so, and yet we 
continue to deny it.

If Europe and APA need OSI, great!  Digital has it now!   But my customers
want DECnet.   And the DECnet customers represent a significant revenue 
stream to Digital.  If OSI can generate the same (or greater) revenue, 
wonderful!   We can afford to do both.   But if OSI can't stand on its own,
put it in the same grave with the VAX 9000.

Bob

    Why does product management insist on ONE product?
    
    DECnet/OSI is a boutique product:  It is aimed at a small,
    price-insensitive, selective niche.  For some customers, even NCL might
    be worth the hassle.
    
    DECnet/VAX Phase IV is a volume product:  It serves the broad middle of
    a market, unable to handle the very high end but very comfortable for
    many customers.
    
    General Motors sells the Chevy and the Cadillac.  They even share code.
    They dont' share markets.
    
    If Cadillac sales decline, GM doesn't cancel the Chevy.

        .46

    >Why does product management insist on ONE product?

    it is not easy for one group to support many versions of the same
    software. 

    once you make new version of your software, you would have fixed
    in it problems that exists in earlier versions, so to keep
    supporting the old version while the fixes and enhancements are in the
    new version just dont make sense.


    we software engineers are already under allot of stress the way
    it is, we dont need more stress by having to support many flavors
    of the same software, we'll go crazy ! (if we are not allready..)

    \nasser

Remember, if you force a customer through a conversion, he will also look at
the cost/benefit of converting to other products.

Bob

    Seems the problem is in the applications.  Most customers that used
    DECnet already have an IP part of their network.  Often, it's MUCH
    larger than the DECnet IV part of their net.  However, customers of a
    decade or more are using applications like VAXmail, VTX, VAXnotes, and
    the vast variety of others.  Digital would fall apart if we had to
    switch to IP only tomorrow, because the applications would stop
    working.  Lots of customers are in the same boat.  When we say "switch
    to Phase V or don't buy anymore hardware", we at least get them
    thinking of how they could cope without Digital.  One answer would be 
    to work on a transparent way for existing applications to think they are 
    talking DECnet, but to have them work over an IP network.  
    
    The Europe wants OSI story is all but false.  Yes, the governments may
    want it to run their customs departments, and lots of folks use a
    different form of OSI (over X.25) to send X.400 mail, but generally,
    most major European companies are using TCP/IP, and buying Cisco
    routers.  I've had less experience with the Asian side of the world,
    but those I've talked to also say TCP/IP is the default, and OSI is the
    'premium' protocol.  
    
    Most of Digital's communications hardware now supports IP.  Our new
    management systems support IP (in fact NetView supports ONLY IP for
    it's first release).  It's the 'strategy' that has not changed yet,
    meaning that some groups are still building products to work only on a
    Digital Phase V network.  It's sad, because while phase V is tied to
    OSI a lot, the management bits are not compliant to OSI management
    specs.  Any product tied to the management component of phase V will
    only work with Digitally produced stuff.... if anything at all :-(
    
    In the upcoming February announcement, the IP stuff is focused on.  One
    marketing line goes something like "Digital brings you the experience
    of 15 years of building networks, now available using today's
    standards".   Digital need not be embarrassed by it's past.  TCP/IP was
    really in bad shape when Phase IV came out.  That was over 10 years
    ago.  It's time for a change.
    
    bill

    .49
    
    How could I ever forget? It must be one of the biggest planets
    that we've got around in the solar system these days...

    Bill, 

    It's amazing that our marketing is not able to produce simple
    explanation of what our plans for DECnet are.

    One should simply document the very few scenarios, "you have THIS P4
    and plan to have THAT P4/P5/IP in the future, here is how to get there with
    phase IV products". Phase V is fully compatible with phase IV and I
    have to think hard about really difficult cases.

    OSI, the GOSIP market alone in Europe is a multibilion business. DEC
    has bid for several billion OSI business in this space already.
    It is amazing that a network marketing person does not know that.

    						wlodek

   How can I forget Jupiter.  Had a major customer wanting to upgrade
   his 1077.  He was hot for Jupiter.  He was all set to buy as soon as
   it was released.  He was P/O'ed.
   
   It's also how I remember one of my best friend's phone number:
   
   		xxx-JUPITER (xxx-2080)

Re:.22

>My final point is, as a Sales Support person who is expected to be able to
>tell customers why they should spend time and money on Digital products as
>opposed to third party products, what do I tell customers when they ask me
>about Phase V?  And more important, what do I tell them when they ask me
>when the Digital Easynet will be completely cut over to Phase V, and how
>long it took to do it, and what problems we encountered doing it?  As far
>as I know, there are no plans to completely convert the Easynet to Phase V,
>so I look pretty foolish recommending that customers do something that we 
>are not going to do.

Digital's EASYnet is running DECnet Phase V software since August 1992 on its
production systems in Europe and APA, and on most systems in the US. OK, 
it's the DECnet/VAX Extensions product (aka Wave 1), but it's Phase V software.
Next summer, these systems will be migrated to DECnet/OSI for OpenVMS V5.7.

Beside the production systems, there are already several thousands systems
which have been running DECnet/OSI quite smoothly... All the routers on
EASYnet are being replaced by DECNISes.

You can tell your customers that EASYnet is transitionning to DECnet/OSI.
We will not be completely cut over to DECnet/OSI until quite a long time 
(actually until DECnet Phase II systems will be retired !), but that is not
important to the matter... 

The migration of the production systems to DECnet/VAX Extensions took 2 months.
Their migration to DECnet/OSI will take 2 months (the preparation of the 
migration is another story...).

There are definitive plans to put DECnet/OSI on most of the production systems 
(those on which our day to day business depends). You might not be aware of
these plans, but they are there. 

Yes, EASYnet is late in its migration to DECnet/OSI, but it is happening... You
can also tell your customer that Digital's network is by far more complex 
than the average DECnet network and planning its migration is not such an easy
job. In a few months from now, the bulk of the migration will be behind us. 
I hope that then, you will let your customer know we made it...

Bertrand Buclin,
EASYnet Net Apps Service Manager,
IT Operations, Europe

    My customers will not migrate to OSI on their own volition.
    
    State of Texas has backed away from any OSI mandate.
    
    Customers are all evaluating TCP/IP solutions.
    
    The only product which will be hurt by all this is VMSclusters
    which at this point in time require DECnet to load workstations
    and perform some system management functions.
    
    All the system utilities VAXmail(via MX), NEWS, and all the open 
    Systems softwares work just fine over TCP/IP and OpenVMS... Almost
    all of my customers will move in that direction
    
    With OSI 6 years late, everyone is wary of it (the OSI folks have 
    been "Just Six more Monthing" us to death for the last six year).
    
    Now as things are breaking in 6.0-6.1 of OpenVMS with Phase IV
    (like the WAN drivers) we are insisting on an OSI migration for 
    our customers who have 2-100,000 nodes.
    
    The customers don't want it.
    
    The Government isn't even demanding it
    
    Our network people finally delivered it...
    
    Sounds like a great set of reasons to go to OSI.
    
    I appriciate that we are a global company, decouple the network from 
    the OS and offer OSI to the world, and let our domestic customers 
    choose TCP/IP, DECnet IV or OSI/DECnet V...
    
    (Given a choice in today's market, TCP/IP is the only way for most
    customers to go in with eventual migration to OSI in the 1998-2000 
    timeframe)
    
    john w
    
    

    After all these years reading notes it still fascinates me how a simple
    question mires itself down into a technical discussion not even closely
    related to the base note.
    
    Ken

    
    The base note question was answered long time ago. There is yet another
    way to say that DEC's problems are greatly exaggerated, did our credit
    rating change ? I did not, we have still same credit rating by
    external finantial institutions as we had during the good years. 
    Maybe this can help you fight fud.
    
    As for phase IV products end of life. VMS land has announced that 18
    months from now we will see last VMS version of pure phase IV product.    
    The official support will end later on, I don't know the official rules
    anymore. So, what we say is that pure phase IV VMS nodes will not get
    new versions or "support" within roughly 2 years time.
    
    Of course lots of customers, including mine , will not migrate within
    this time frame and I'm sure we will be supported, either on project or  
    "customer satisfaction" basis. One should not anticipate many new problems
    with these products either .
    
    Now phase V has phase IV compatibility built in, this is a part of the
    architecture . DEC has actually the best
    story in the industry to tell about backwords compatibility. Phase IV
    product set ships since 12 years ago and phase III compatibility is
    actively suppored . There are customers out there runing phase III and 
    we will still fix any phase IV compatibility problems next 2 years.
    The risks of findiong any is though close to 0.
    
    A phase IV node is happy to live in phase V network and phase V node is
    happy in the phase IV network ( but new features are obvilsuly not
    available). Pick any option you like.
    
    In the long run I see my customer go to phase V end nodes in phase IV 
    network and then slow migration of the backbone to the multiprotocol
    routing. But on the protcol level we will certainly run phase IV many years
    from now.
    
    Lost of debate here seem "false" to me. The industry is in the middle
    of technology change. SNMP in US is defacto standard for network
    management for all new comms products. All new products do TCP and
    other protocols. Our customer base in US was facing a technology change
    even if we supported phase IV nodes untill 2017 . Phase IV/V issues
    have nothing with this to do. The real issue is migration to
    multiporotocol routing.
    
    

    
>    Lost of debate here seem "false" to me. The industry is in the middle
>    of technology change. 
.
.
.
>    Our customer base in US was facing a technology change
>    even if we supported phase IV nodes untill 2017 . 

So the hell with the customers if they're too stupid to keep up with us, eh?
We'll get lots more customers.  Who needs dinky little US firms like GE.

Its exactly this arrogant attitude that has placed Digital in the dire
straights it is currently in.

Wonderful news for the next Xyplex (Digital: "LAT is better than TELNET... the
world will change."  Result: Digital goes from 99% ownership in the terminal 
server market to about 30%, and only maintains that with the addition of
the 'inferior' TELNET capability.)

SUN Microsystems loved it  (Digital:  Unix is snake-oil - VMS is the salvation 
of mankind.)  

Great for the next Cisco too, but we've been through that.

And we all know that the Rainbow PC will be the envy of the world, but
we've been through that too.

(sigh)  I sometimes wonder if I'm the only one listening to our customers.
    
Bob

    
    
    	Bob, you missunderstood my point completly. 
    	Your customer has options, one of these is to stay at phase IV for
    	several years . Phase V is an option , TCP/IP is an option. 
    	
    	Phase IV VMS products end of life is a bussines decission. If you
    	think that the impact is just too big do somthing about it , but
    	notes is not the way to go. GE has an account team that sure does
    	not want customer problems. Personally I don't think that
    	VMS/DECnet decission was particulary wise. I have forwarded my
    	comment to OSI marketing.
    
    					wlodek
    

GE Corporate Account Manager is already in the loop.

And I agree the decision needs to be revisited.

Bob

    So like, let's get all the OSI people in a room and just....
    
    (CENSORED)
    
    
    There is no technical or business advantage to force ANY of my 
    customers to OSI at this point in time.
    
    Any required/forced migration will be the end of DECNET as a market 
    and the final card delt in ceding the network market to entirely 
    to TCP/IP.
    
    I have made customers desires known to the OSI groups, they have 
    no real plan to help me or my customers extend their Phase IV
    investment (WAN drivers is a perfect example of this), so my customers 
    have nodesire to support a direction that adds no value to their 
    current network.
    
    I have no desire to go against my customers wishes -- I will support 
    my customer's decisions to move to TCP/IP instead of DECnet phase V
    
    And I will laugh when the OSI teams are TFSO'd next year...
    
    You either add value in today's market or you don't sell your product,
    I'm past talking, I'll let the market kill the OSI group within 
    Digital...
    
    Ignore the market at your peril Digital Engineering Groups, the times
    they are a changing...
    
    John Wisniewski
    

    RE: .61 And I will laugh when the OSI teams are TFSO'd next year...
    
    
    Pretty cold and stupid thing to say.
    
    
    Mike

    
    re: .61
    
    Given the impersonal nature of notes conferences, I guess I'm not
    surprised to see statements like these.  I'm sure that if you knew any
    of the DECnet/OSI engineers, your attitude would be much different. 
    Having worked with the DECnet/OSI teams off and on for about five
    years, I have the utmost respect for the DECnet/OSI people and their
    work.  I would deeply regret the loss of any of these people.  I think
    that your statement is myopic and misguided.
    
    Ken 

    re .61
    
    I have no axe to grind on this, and think that .61 is pretty tactless,
    but if customers have repeatedly expressed concerns and their concerns
    have been escalated and ignored, you can understand how folks in the
    field feel.
    
    What is the forum for getting these requirements into the system, and
    implemented for those who are not interested in Phase 5?
    
    Remember, these customers pay our wages. Well, your wages - I've been
    TFSO'd and am out of here on Friday. Unless you're keen to join "the
    club" I'd suggest their opinions are VERY important to your pay checks.
    
    Gary 

    
    Gary,
    
    You are indeed correct.  I suspect, however, that many of these folks
    may have tried to change things but have been shot down.  I am only
    speaking from my personal experience.  Talk about the problems and
    solutions and don't wish people out of jobs.
    
    
    Good Luck in your future outside of DEC.
    
    
    Mike

OK, so maybe .61 was a bit raw in stating his opinion.
You HAVE to see the other side of the coin:  When an engineering group
ignores major customer input like in this case, they are not
WISHING TFSO on someone, they are ACTIVELY WORKING on getting countless
field folks shown the door!  If they don't sell (or assist sales in the
case of sales support), they are TFSO'd.  

If customers get so PO'ed at our networks that they no longer consider
our networking products which is happening as we speak, how much value 
does a network specialist in a field office add?  You are directly getting
people laid off if you don't listen to major customer input on this one.

How would you feel in the other guys shoes?

Kevin Farlee
-been there-

           <<< HUMANE::DISK$DIGITAL:[NOTES$LIBRARY]DIGITAL.NOTE;1 >>>
                        -< The Digital way of working >-
================================================================================
Note 2846.61                   Kiss Of Death Rumor                      61 of 66
DPDMAI::WISNIEWSKI "ADEPT of the Virtual Space."     32 lines  22-JAN-1994 13:02
              -< Ignore the market -- Get a free TFSO process.. >-
--------------------------------------------------------------------------------

>    So like, let's get all the OSI people in a room and just....
>    
>    (CENSORED)

	COUNT ME IN!  Every time I've gone to something that's been 
	(CENSORED), it's been REALLY GREAT!!!  In fact, when we put 
	together the distribution list, we'll make sure you're on it!


           <<< HUMANE::DISK$DIGITAL:[NOTES$LIBRARY]DIGITAL.NOTE;1 >>>
                        -< The Digital way of working >-
================================================================================
Note 2846.55                   Kiss Of Death Rumor                      55 of 66
DPDMAI::WISNIEWSKI "ADEPT of the Virtual Space."     40 lines  18-JAN-1994 14:50
              -< My customers just don't want to move to OSI... >-
--------------------------------------------------------------------------------
    
>    (Given a choice in today's market, TCP/IP is the only way for most
>    customers to go in with eventual migration to OSI in the 1998-2000 
>    timeframe)
    
	I can't think of another instance when Digital has anticipated
	market demand by having its product set ready this far in advance.
	Thanks for your endorsement of the DECnet/OSI strategy!

Ken Roberts
DECnet/OSI Engineering
    

>         <<< Note 2846.67 by BULEAN::ROBERTS "Are your lights out?" >>>
>              -< Just to let you know that we *are* listening... >-

>>================================================================================
>>Note 2846.61                   Kiss Of Death Rumor                      61 of 66
>>DPDMAI::WISNIEWSKI "ADEPT of the Virtual Space."     32 lines  22-JAN-1994 13:02
>>              -< Ignore the market -- Get a free TFSO process.. >-
>>--------------------------------------------------------------------------------

>	COUNT ME IN!  Every time I've gone to something that's been 
>	(CENSORED), it's been REALLY GREAT!!!  In fact, when we put 
>	together the distribution list, we'll make sure you're on it!

    
    Go on Ken, Laugh it off.  The people who are responsible for our
    OSI and UCX products better wake up and smell the coffee or the 
    market will speak and when it does, don't expect a good reference
    or a DECnet based market to sell yourself back into.

    
>>    (Given a choice in today's market, TCP/IP is the only way for most
>>    customers to go in with eventual migration to OSI in the 1998-2000 
>>    timeframe)
    
>	I can't think of another instance when Digital has anticipated
>	market demand by having its product set ready this far in advance.
>	Thanks for your endorsement of the DECnet/OSI strategy!

    I can Ken, it's called PRISM and they dusted it off and renamed it 
    Alpha... 5 year later....We were late to the RISC market and we're
    in an uphill battle.  At least we seem to be delivering to the market
    what they want in Alpha...
    
>Ken Roberts
>DECnet/OSI Engineering
 
    Well Ken, You and the UCX folks wait until the end of the century, 
    and tell me if a market emerges...
    
    Me I'm sick of waiting.. I'm selling Multinet and mainstream network
    stuff until the market wants something differnet.
    
    Bad Jokes about OSI hitting home?  I've got reference books and info
    from 1987 saying OSI is just six months away... If we would have 
    delivered Phase V in 1988 maybe TCP/IP wouldn't have happend but 
    it did happen and Digital missed out...
    
    Novell, NETbios, TCP/IP, SNA, and DECnet Phase IV have markets...
    
    Phase V will not; at least in time to make any payroll at DEC...
    
    Tell me this is the first time you've heard this  and I'll appologize, 
    but the field has been feeding this information back for at least
    two years to engineering...
    
    And what about the sensing at SF DECUS about Phase V?
    
    Network University? The Partner's programs?
    
    John Wisniewski
    Consultant North Texas/Oklahoma
    
    (Who know exactly how tactless and mean he appears in this note,
     but consider how tactless and mean the OSI folks are in causing
     the next wave of field TFSOs for all that DECnet/OSI expertise 
     we no longer need in this company...)
    

    	By a strange chance, yesterday I received in the post a package of
    advertising material from a company that specialises in giving
    technology seminars. A couple of years ago I did a short presentation
    at one of their seminars, and typically they last 2 days, and get 600
    to 1000 people paying $1200 (approx) to attend.
    
    	For one particular seminar the leaflet says in large red letters
    across the top "OPEN SYSTEMS SECURITY". In slightly smaller letters
    below it says "ITSEC, OSI, X.400, X.509 & EDI Security".
    
    	Somewhere on the second page, right at the end of the list of
    seminar topics, it says "UNIX security" and "Kerberos" in the smallest
    size print on the leaflet, but that is the only place those are 
    mentioned. There is no mention of TCP/IP at all while OSI is mentioned
    a number of times in largeish print.
    
    	Now maybe this company hasn't done its market research this time,
    but they have been operating successfuly for a number of years. Or
    maybe it's because the seminar is in Europe (London, to be precise).
    Now Europe provides significantly over 50% of DEC's sales, while the
    U.S. provides only around 40% - it is a larger market in general with
    50% more population than the U.S..  I am not saying we should scrap
    either TCP/IP or OSI, but if we are forced by lack of engineering funds
    or manpower to scrap one of them it seems fairly clear from the above
    that it is TCP/IP that should go.
    
    	Or maybe people in the U.S. are ignoring DEC's market, 60% of which
    is outside the U.S..  To scrap OSI now in favour of TCP/IP would be
    rather a case of the tail wagging the dog.
    
    	(I did hear a rumour that there is a fundamental security problem
    with the TCP/IP protocols, such that they can't be made secure without
    machines using a revised version of the protocol becoming unable to
    talk to any existing machine that talks TCP/IP. If you are going
    through that trauma in your network you might just as well switch to
    OSI as to some future version of TCP/IP, which hasn't even been defined 
    yet. However, I am not a communications protocol expert, so I can't 
    confirm this, but maybe they just decided to skip over TCP/IP in a
    seminar with security in the title).

    Re: .69
    
    January 17th issue of 'Network World' had a headline that read somthing
    like 'Feds suggest dumping GOSIP' so it looks like OSI might be losing
    some ground.

>>    And I will laugh when the OSI teams are TFSO'd next year...

>>    Phase V will not; at least in time to make any payroll at DEC...

>>    ... but consider how tactless and mean the OSI folks are in causing
>>        the next wave of field TFSOs ...

It scares me to know that we have people speaking from such ignorance 
representing *our* company to *our* customers.  I guess somebody has to
have tunnel vision, but it is dangerous to the company.  Read up a bit on
the market before you claim to be an expert.  Gee, I'm starting to get the
impression that DECnet/OSI is the *only* product Digital sells, and that we
only have customers in Texas.

Ed Taranto
DECnet/OSI Engineering

         <<< Note 2846.71 by BULEAN::TARANTO "You want to do what?" >>>

>>    And I will laugh when the OSI teams are TFSO'd next year...

    Did I get your attention with this statement? Good I ment too...
    
>>    Phase V will not; at least in time to make any payroll at DEC...

    Phase V will be a bonanza for the OpenVMS TCP/IP providers over the
    next 12-18 months... Don't look for our TCP/IP product to gain any 
    ground...
    
>>    ... but consider how tactless and mean the OSI folks are in causing
>>        the next wave of field TFSOs ...

    I'm heartless on this but the market is being really cruel right 
    now...and our customers are even crueler... Talk to Mobil, talk to
    DOW, Talk to FMC check out what the Internet Customers have to say...
    
    
>It scares me to know that we have people speaking from such ignorance 
>representing *our* company to *our* customers.  I guess somebody has to
>have tunnel vision, but it is dangerous to the company.  
    
    Ed, All I know is what our customers are telling me.  US goverenment
    is back peddling, Texas State Government has said that OSI may be
    required, much later in this century. 
    
    Customers are converting their VMS systems to TCP/IP to conform with 
    the rest of their networks (they like having to only use one protocol 
    and one set of network expertise)
    
    I'm tired of educating them on the technical nuances of why DECnet 
    is better than TCP/IP or why our implementation of OSI is going to 
    make life as we know it better.  That type of education increases
    the sales cycle dramatically and is only a delay for a LAN sale
    while something besides TCP/IP is evaluated. 
    
    We're going to sell something that does the job and move on, just as 
    good as our competition ... If that something is TCP/IP then so be it...
    
    Our customers in Texas have committed code to the DECnet stack, 
    used the WAN drivers, and async DECnet for solutions. They are 
    asking me why stuff Breaks in V6.0 of OpenVMS (WAN drivers NICE
    interface, etc), how adding an OSI protocol to their network will 
    impact it with yet another protocl on the wire to deal with?
    
    As OUR customers in the central United States evaluate simplifying
    their networks over the next several years OSI isn't in the PLAN..
    TCP/IP is. If OSI isn't in the plan neither is DECnet phase V...
    
    >Read up a bit on the market before you claim to be an expert.  Gee, 
    >I'm starting to get the impression that DECnet/OSI is the *only* 
    >product Digital sells, and that we only have customers in Texas.

    Talk to our customers a bit more before you ram yet another 
    DEC-Architected/Built product down their systems (which they didn't 
    ask for and don't want (right now)).  
    
    We were supposed to be decoupling DECnet from the OS to allow 
    divergence and customers who wanted to stay at a specific version 
    of DECnet to do so.  We decoupled... and spent no money to keep
    Phase IV stuff working or even maintained.
    
    Read comp.os.vms  the customers are blasting us for letting the 
    Phase IV WAN drivers stop working.  They've been ranting for the 
    last three months on comp.os.vms and comp.sys.dec and vmsnet.* 
    about all of this -- (where have you been in these customer discussions?) 
    
    Last time I checked the internet newsgroups weren't just in Texas...
    
    No, I'm just a flake from Texas, the customers on the Net are just
    some Unix Weenies, the folks at DECUS are only ... What does it 
    take to convince you folks that we have a problem here... 
    
    Our networking Product/Architecture DOES impact all our other 
    products and is a lynch pin which we hang all sorts of solutions
    and functionality.  Go off on a tangent from the market and we
    find ourselves in the field scrambling for third party solutions,
    and having to deal with customers who are riled up about arbitrary
    changes to their enironment.
    
    Europe and the Far East is a big market but the US will be taking
    another path and we'd better be prepared for it.
    
    Step 1: We better have a world class TCP/IP offering for OpenVMS, 
            and OSF/1.  Today OpenVMS has been struggling with this and
            we'd better fix it, or just redistribute Multi-net
    
    Step 2: Allow customers to stay with their Phase IV DECnet
            implementations.  Not with emulation or multiple stacks
            but by making Phase IV WAN driver code work on OSF/1 and 
            OpenVMS VAX/AXP.
            (Yes I know this is a step backwords but customers are
             asking for it. Customers remember them?)
    
    Step 3: Phase in a migration to OSI at the customer's convenience
            and target a phased approach until 1999...
    
    We've left our existing customers in the lurch and they will move
    to TCP/IP... Customers have long memories.  Good luck winning them 
    back to DECnet/OSI if they leave...
    
    I've been polite in this thread compared to the beating I've taken
    for our side in the Internet groups.. When people start ASKING
    for OSI, then I'll believe there is a market...
    
    
>Ed Taranto
>DECnet/OSI Engineering
    
    John Wisniewski
    OpenVMS Partner North Texas/Oklahoma
    Counsulant II
    

Re: .72

TCP/IP Services for OpenVMS (aka UCX) V3.0 seems to have some nice stuff
that customers I support have been wanting. It is available on the Alpha now
and will probably be out for VAX/OpenVMS soon.

BTW, do you realize that the Texas is the entire US and the US is not 
representative of the our business in general?  Much of the drive
for DECnet/OSI is from Japan, Australia, and Europe.  Funny but those
areas represent a significant majority of Digital's income.

The decision may not make sense in the US or Texas but overall considering
our markets it does make sense.

And I have been in the conflagurations on USENET.  Sadly I have to correct
other Digital employees who post incorrect information on Phase V.  One
thing to understand about USENET is that it is not a valid cross-section
of customers.

Uh, we do have a world class TCP/IP with OSF/1.  And if you haven't noticed,
the majority of the post regarding DECnet/OSI for DEC OSF/1 have been very
favorable.  Reality sucks, doesn't it?

As for port WAN drivers ... buy a clue.  One of the major reasons for the
V6.0 problems with the WAN drivers in that they fairly unportable.  There
is NFW that they could be ported to a non-VAX or non-VMS environment in a
reasonable amount of time.  It is easier and faster to port the ULTRIX
(now OSF/1) code to VMS than to any other alternative.

The vast majority of install VMS/DECnet systems have need for WAN
connectivity.  And that small percentage that do are responsible for
the majority of calls and product requirements as company Frozbozz
wants to speak a certain dialect of HDLC (well almost HDLC) and then
they want to us to help them.  OK, either you can loose the sale up
front or you can eat any profits and then the rest of the sale income
in supports costs?  You may have noticed that Digital is still losing
money.  Sometimes you just have to walk away.

Lastly, every ones budget is being cut.  Now we have the resources to
either work on 1) Phase IV for about $300 million or 2) Phase V for 
multiple billions of $$ worth for major SI projects over many numbers
of years.  Where would *you* focus your efforts?

Do you remember the Phase III to Phase IV days?  De javu all over again.

RE: .61

I am shocked at your insensitivity to the human beings who are working so hard
for this company.  Rather than causing field people to get TFSOed, the DECnet
and UCX projects are helping to save and/or create many jobs for people in the 
field, especially in the systems integration and key customer account areas.

Your comments are especially out of context when you consider that the
engineering team that has been enhancing the old Phase IV code base is the
same group that delivered DECnet/OSI.  You seem to ignore what would seem to 
be key pieces of data:

	- The DECnet program continues to be one of the most profitable
		programs within Digital
	- Modifications in DECnet/OSI to support specific customer needs
		have been instrumental in winning NEW customers via the 
		corporate systems integration program.
	- The UCX program continues to grow in profit each year, despite an 
		overall slowdown or dropoff in VMS system sales.
	- Less than 6 months ago our group proposed dropping some of the
		GOSIP certifications.  The uproar from the network partners
		and other field people (particularly outside the U.S.) 
		required that this work be retained.
	- Even if you do not feel the need for OSI, your belief that we can
		backup to Phase IV in not correct.  Most of the changes in
		DECnet from Phase IV to DECnet/OSI were to address problems
		in DECnet Phase IV, not to address OSI issues, and were 
		brought to our attention by the customers.

Hopefully you provided your input to the appropriate people, namely the
product managers responsible for defining the product requirements.   If so,
I'm sorry that your ideas didn't get accepted.  

I'm know that the people responsible for these products (myself included) 
have made mistakes in deciding what we should do in these products, after
all we are only human.  The data above would indicate that these people have
also made many correct decisions, resulting in positive profit for this 
company.  

Rather than blame the DECnet and UCX development groups for the problems in 
the field, or state that people should laugh if these groups get TFSOed, I 
would like to thank the DECnet and UCX groups for helping to keep the 
corporate situation from getting any worse than it is.

Bill Duane
NOS Technical Director (and ex-DECnet/OSI Technical Leader)

    Re .several
    
    If people would not focus on the "/OSI" bit of "DECnet/OSI" and instead
    focus on the "DECnet" part they'd find it easier to change their
    mindset.
    
    In my mind the marketing message for this thing called "DECnet/OSI"
    should be:
    
    We've improved your tried and trusted DECnet Phase IV. We've moved to
    Phase V. It is Phase IV+. You don't lose anything important. User
    programming interfaces are backwards compatible. If they're not Digital
    will fix them so that they are.
    
    Oh and by the way you get some OSI capabilities as well.
    
    Instead our "brilliant" marketing folks have been focusing on scaring
    customers into thinking how difficult it is to upgrade from Phase IV to
    DECnet/OSI. They even called it "Advantage-Networks" on the way just to
    confuse everybody.
    
    Folks, upgrading to DECnet/OSI on an end node VAX system is no more
    difficult than answering half a dozen questions. Sure you need one
    Phase V router to keep cluster alias (here I think the developers did
    screw up, cluster alias is a user level function). But I don't consider
    that to be a major problem.
    
    And no I'm not in the DECnet development team. And yes I was one of the
    people that made a BIG fuss when the DECnet/OSI group thought it would
    be OK to release DECnet/OSI when layered products wouldn't install
    without change. Luckily they saw the error of their ways and now
    include a pretty good NCP emulator.
    
    Please folks look at what is shipping NOW. Not what was shipping 1 or 2
    years ago. It is much better. Even the NCL HELP now HELPs rather than
    perplexes.
    
    I say if you haven't installed DECnet/OSI V5.7 (aka WAVE3) you have no
    right to complain. If you do find problems then tell the developers.
    
    Dave

    Hi

    I was told this was a good note to read... so whilst I'd much rather be
    doing something far more fun and energetic at this time in the evening, it
    seems it's time to join in.

    Firstly, as it's late, let me save you the energy of putting authors into
    pigeon-holes before reading the content. If it makes you feel good then
    please call me:

    		- an OSI bigot
    		- a Euro bigot
    		- a DECnet bigot
    		- some other sort I've not thought of yet
    		- all of the above...
    		   (btw I can't spell either)

    I hope none of the 1st three apply, but I'll not attempt to defend myself,
    but I would like to claim to me a "Digital-Bigot".

    Aside from the fact I know who pays the rent cheque, I also enjoy working
    for Digital because of the products, architectures and Engineers who make
    it happen. 

         [It's just a little tiring to have to also work with a minority who
         appear intent on stopping it happening]

    I'd like to see that we all Win.

    To do so we have to satisfy the markets we work in, and whilst it's clear
    that some of the previous writers only consider the US subsidiary to be
    significant, I think it will help the bottom line if all the subs win.

    So:
    		1: We must not halm the US sub... so lets see what can be
    		   done to keep products coming which meet their requirements.

    		2: As significantly > 50% of the DECnet revenue stream comes
    	 	   from outsite the US sub, then how about making sure this
    		   thrives too. Please let the non-US representitive
    		   decide how this is best achieved and don't keep telling
    		   us our job.

    I can see no point in having a deep and technical discussion on DECnet or
    DECnet/OSI or OSI or TCP/IP or IPS here.... as few of the discussion before
    has been based on technical fact, mostly on opinion and our local view of
    the world.

    So, lets me give my local view... If you don't like it then please skip
    this and the next couple or 10 notes.

    I've just returned from my prime customer, F.Hoffmann-La Roche. Ok, I
    assume they are not as big as all these US-Sub companies we hear about 
    (GE etc) but they happen to be the richest drug company in the world, the
    2nd largest Swiss company, and I like them. They also like Cisco - in fact
    they like Cisco to the exclusion of all else.... so it might not seen like
    a fruitful place to be working.

    The purpose of the meeting which kept me so late was to finalise an IT
    architecture document, where they state OSI and TCP/IP are their target
    network environments.

    Now, I've worked quite hard to keep them focused on DECnet as the majority
    of their research network is based on it, but no, they want OSI and TCP/IP.
    What a shame....

    What can I do? Shucks, I have to let them use DECnet/OSI. 

         [Actually they funded a project to ensure they are ready for
         DECnet/OSI last September. It will cost them only SFr1.5M (SFR = $
         approx). This is quite cheap compared (i) to the cost of upgrading to
         OpenVMS V6.0 and (ii) is 1/200th of the cost of reengineering their
         DECnet applications to TCP/IP]

    Now, if you ask Roche:

    	"Are you migrating to OSI"		they would say	"NO"
    	"Are you migrating to TCP/IP"		they would say 	"NO"
    	"Are you sticking in DECnet-VAX"	they would say	"NO"

    Strange huh.

    Not really - they are quite typical of most of the customers I work with.

    The point is - they are also not bigots. They do not see the world in
    the same BLACK_and_WHITE way that appears to be so prevelent in the US
    subsidiary. 

    What do they See?

    	They see that:

    	DECnet IV is Proprietary .qed. bad
    	TCP/IP is a widely used defacto standard .qed. good
    	They have alot of DECnet application and users like the interface
    	Many government organisations they work with require OSI conformance
    	They like X.400 and X.500
    	They also would like to run a single Network Layer Protocol
    	The IETF is currently working on plans for the future IP
    	They want a sucure but flexible path forward

    Given all of this, and given the overriding cost arguments, they WANT
    DECnet/OSI because it:

    	- leaves the user interface unchanged
    	- integrates better with TCP/IP
    	- allow use of OSI applications
    	- allows elimination of the proprietary DECnet network protocols
    	- is simple upgrade (compared to OpenVMS V6.0 or ORACLE V7)

    So thats it...

    This is only one view. 

    As this note is getting long and I'd like to change gear a little, and sign
    off now with one final comment and request:

    	- To return to the topic in .1, and the discussion of our iminent
    	  demise in favour of IBM, then it would appear we have one major
    	  feature that IBM either does not have or has cured. We talk 
    	  ourselves into DEEP_Dark_Black_Holes better then anyone in the
    	  industry.

    	  Luckily (in this case) our external communications are a little
    	  less good, so the customers generally like us better then we
    	  like ourselves... 

    	  So PLEASE let work together.

         The US subsidiary clearly (according to these notes) has some  fairly
         extreme requirements which are generally unlike many other parts of
         the corporation. We MUST meet these whilst not killing off the other
         parts.

    If you want to work for a US-only organisation please go do so.

    If you want to work for Digital then lets try to find a path thru this
    which keep all the subsidiaries (even little Switzerland) alive and (better
    still) thriving... 

    Regards

    Bob
    

    Ok - so part 2, lets answer some of the points raised:

>Note 2846.14 SYORPD::DEEP "Bob Deep - SYO, DTN 256-5708"
>The network partners have voiced their concerns to Networks Engineering,
>but to no avail.

    Correction.

    Some US-Partners have voiced their concern [re DECnet/OSI] to Networks
    Engineering.

    It's not clear to what extend this is representitive of the world view
    which the Network Partners is generally assumed to try to form.

    What is true is that a number of Network Partners (who happen to be not
    based in the US) have expressed their concern over the level of FUD and
    general misinformation being circulated on this subject (see following
    notes).

    I note with interest the number of non-US contributions to the topic here.
    Please take account of the following:

         - you have a major advantage in speaking English (or one of the local
         variations as used in the US) and therefore find 'sounding off' in
         notesfiles and mail quite easy. There is a natural reluctence in some
         other subsidiaries to writing in a foreign language whilst still
         remaining clear, so you should not attempt to win arguements by pure
         weight of replies.
    		[I am just about to go against my own advise here but
    		that just shows I am not always consistent]

         That said, I suspect the main reason for the lack of balance in this
         note is nothing to do with language... but

         - Many of you appear to have very ready access to non-technical notes.
         How you find the time to do this after working with customers, selling
         and leading, plus also keeping up technically with the products 
         (eg DECnet/OSI) so you really understand then, whilst also providing
         timely and tell thought out feedback to engineering and product
         management is amazing. You must work very late. Unfortunately many of
         use are out of the office (on customer site) most of the time and
         access to US notesfiles in the US daytime (evening in  Europe) is not
         great.
    		  
>Note 2846.50	SKIBUM::GASSMAN
>    
>    The Europe wants OSI story is all but false.  Yes, the governments may
>    want it to run their customs departments, and lots of folks use a
>    different form of OSI (over X.25) to send X.400 mail, but generally,
>    most major European companies are using TCP/IP, and buying Cisco
>    routers. 

    Oh ... I must tell Roche. It will come as a suprise. I think they
    thought they were a major European company.

    Of course it would be nice for us all the US government was all powerful
    and could simply dictate the rules for all Governments worldwide, but like
    it or not there are many Governments who do specify OSI requirements today.

    Until such time as this situation changes (if it does) then don't you think
    it's a little short sighted to miss out on all these non-US governments and
    their related industries.

    Incidently, did you read the article circulated recently from Boeing, a
    fairly well known US organisation with a big interest in TCP/IP. I quote
    selectivily to support my own arguement, go read the whole thing if you
    doubt it:

>Reprinted without permission from ConneXions, Volume 7, No. 9, September 1993.
>
>		the networks of many large corporations are currently being 
>driven by sets of strong, but contradictory, requirements:  one set demanding 
>compliance with Internet Standards and another set demanding compliance with 
>International Standards.  [Note:  The following is a single example concerning 
>why International Standards are important to large corporations.  Corporations 
>conducting a global business are subject to the regulations of those countries 
>in which they trade.  International commerce is regulated by governments, many 
>of whom have placed restrictions upon data communications.  These restrictions 
>affect the data communications of a corporation's products as well as the data 
>communications between corporations (i.e.,  business partners, customers, and 
>suppliers).  International Standards are the only certain bet to comply with 
>world-wide commerce restrictions.]  


>Note 2846.24   LGP30::FLEISCHER
>  
>        I know that it's all too easy to say this in retrospect, but
>        this whole DECnet Phase V/OSI thing was a LARGE mistake.

    Maybe it was, may be it wasn't.

    There is a chance (not so small, actually I think about 70%) that we could
    be in just the right place. Some tweeking need to be done (mostly in the
    direction of TCP/IP integration and ONE additional NCP command) but we'll
    have to see.

    What is clear is that running down Digital, DECnet, Engineering, and the
    world as a whole is not going to fix it...

    Positive and constructive discussion, feedback at the appropriate times,
    technical awareness outside out immediate world, there will all help.

    Shooting ourselves (or our colleagues) in the foot will not.

>Note 2846.30     ROWLET::AINSLEY 
>                 -< NCL = Networkengineer Confusion Language >-

    It's odd - the same people who found X.25 and PSI difficult and complex
    (all those troublesome NCP commands) also appear to have a mental block on
    NCL. I am sure there is a conclusion to draw here...


    Regards

    Bob
    

    So....

    I've certainly taken up enough byte-space already, but I'm on a roll so
    here comes alot more.

    What follows is a letter we wrote to Larry Walker (VP Network Engineering)
    last week, when some of this heat/light/sound was appearing to be becoming
    overly one-sided and non-representitive of the worldwide Network Partners.

    Given the problems of getting 10 people to all read mail and reply on the
    same day, I did not at the time claim to represent more than my view and
    those of the co-authors.

    However,  Since sending it, I've had some replies from other network
    partners. I am posting these as well, plus some other mails so help provide
    an wider prespective on the discussion. Please skip these notes if you have
    a closed view of the world and do not wish to look outside your own litle
    part of it.

    Regards

    Bob

                  I N T E R O F F I C E   M E M O R A N D U M

                                        Date:     17-Jan-1994 18:07 CET
                                        From:     Robert Watson @ZUO
                                                  ZUREDU::RWATSON
                                        Dept:     Digital Consulting
                                        Tel No:   760-3340

TO: 	Larry Walker, VP Network Engineering		(DELNI::WALKER)
Cc:	Bill Strecker, VP Engineering		 	(PNDVUE::STRECKER)
    	Don Harbert, Computer System Group		(STAR::HARBERT)
    	Judy Cross, Product Manager DECnet/OSI		(DELNI::CROSS)
	
    Larry,

    I am writing on behalf of a number of European Network Partners. You will
    be aware that following the recent US Decus event there has been
    considerable discussion in the US area concerning our strategy for DECnet
    and DECnet/OSI, and specifically the plans for the retirement of
    DECnet-VAX.

    We are concerned that much of the comment on these plans (both externally
    and internally, and notably amounght the US Network Partners) has been
    poorly informed and is leading to a panic reaction and decisions which are
    not well considered.

    Contrary to comments we understand have been made in the US press, and on
    the Network Partners list, we are _not_ dropping DECnet Phase IV, it's
    fully support in DECnet/OSI. We are also _not_ forcing customers to use
    OSI. It is entirely optional in DECnet/OSI whether the OSI applications and
    protocols are used. Our customers understand this, because we worked with
    them and explained our plans. If there confusion in the US market then this
    is more to do with our communication with the customers at an account level
    than the strategy. 

    The worldwide network partners meeting has not been held this year, and
    many European Partners have been unable to attend the replacement regional
    Network Academy meetings, and so we are concerned that at the forthcoming
    US Network Academy meeting you may come under considerable pressure from a
    US-centric point of view to significantly alter our strategy in the area of
    DECnet and DECnet/OSI. 

    We support the joint TCP/IP +  DECnet/OSI strategy, and with the current
    developments with reference to IP 'next generation', we stand a good chance
    to be very well positioned to have a complete product capable of running
    the Connectionless Network Protocol (CLNS) supported by the TUBA solution
    to IPnG, with more experience on Routers and End Systems than anyone in the
    industry. 

    There is room for some 'fine tuning' with respect of the rollout of
    DECnet/OSI (notably in the area of Network Management), but any significant
    alteration of delay in the delivery of the DECnet/OSI product set,
    specifically the DECnet/OSI V6.0 on OpenVMS VAX & AXP, CLNS support on PC's
    and further development of the OSI + TCP/IP routers will severely damage
    the Digital presence in a large number of European Customers.

    Customers such as Hoffmann-La Roche, Swiss PTT, Britsh Aerospace, ICI, ABB,
    and the High Energy Physics Network have made significant investments based
    on the Digital strategy, and depend on us to help them through the current
    uncertainties with respect to both TCP/IP and OSI. This list is based on
    our personal experience. Contact with other European Partners will show
    similar activities in many of our major customers. This is supported by the
    interest shown in DECnet/OSI sessions at the European Decus and other
    requests for DECnet/OSI service and support.

    Please, delays and sudden direction changes will kill much of the work we
    are doing with our customers. We need some vision, and we need to stick
    with our plans and drive them to completion. 

    If it turns out that the TCP/IP world will move to use CLNP, then we have a
    _huge_ lead and are taking our customers down the precisely correct path.
    We have the fastest CLNS router in the market (4-5 times the performance of
    Cisco according to Bradner) and a complete end system support. Our greatest
    fear is we will miss this chance to retake the lead.

    If the TCP/IP world chooses to move some new and untried network layer
    protocol then we are protecting our customer's investment in Digital and
    DECnet until the dust settles, and then we can work with them to move to
    the new platform, when this as reliable and well supported as DECnet/OSI
    and DECnet before it.

    We are not claiming that everything is simple and clear and appreciate some
    difficult decisions may have to be made. All we ask is that these decisions
    are made with a 'world view'. 

    Please contact us if you require further details or clarification on any of
    the points raised, and we look forward to being able to contribute in a
    positive fashion to ensure our strategy leads to success for all parts of
    Digital.

    Regards

    Bob Watson, Switzerland
    Ken Punshon, UK
    

	The following mail is posted without the express permission
	of the author, as this could not be obtained at this time.

                  I N T E R O F F I C E   M E M O R A N D U M

                                        Date:     21-Jan-1994 13:19 CET
                                        From:     Patrick GROSSETETE @EVT
                                                  GROSSETETE.PATRICK AT  A1_EVTAI1 at FRMRC at EVO
                                        Dept:     Customer Services
                                        Tel No:   858-1318

TO:  ROBERT WATSON @ZUO

CC:  Patrick GROSSETETE @EVT              ( GROSSETETE.PATRICK AT  A1_EVTAI1 at FRMRC at EVO )

Subject: DECnet/OSI mail to Larry Walker

	Bob,

	I fully agree with your mail, you sent to Larry Walker.
We have been working with customers for year about a transition to
DECnet/OSI. That will be a very huge problem if we cancel the current
plans about DECnet/OSI. I won't be the guy who will explain to some
large customers that all consultancies they paid to Digital for the 
transition have just been there to help us to lay off people...

	I really think that we are on the right track with the DECnet/OSI
v.6.0 plan if we must improve our TCP/IP integration. 

	I monitored DECUS France Network SIG and can tell you that
DECnet/OSI is now well received even if they are still some discussion
about the lack of Host Based Routing. I am pretty sure that if we include
the IS-IS kit in a super license of DECnet/OSI, a lot of noise will
shut off.

	Below is a list of large customers which are known in France 
as working on DECnet/OSI. We must not forget all small sites which
installed DECnet/OSI because we sold them routers or just installed
DECnet/OSI because it was the way of future (at this time).

	Best Regards
	Patrick

. Institut Francaise du Petrole (I.F.P.)
	They alreday have most of their systems running DECnet/OSI

. Cofiroute
	They were our first customer to buy DECnis and WANrouter 250

. Michelin
	We worked on their transition plans

. Renault Vehicules Industriels
	We worked on their transition plans

. Cogema	Contact Michel Guesdon 
	We worked on their transition plans

. St Gobain	Contact Aurore Dousset
	We worked on their transition plans


. S.T.N.A.	Contact Isabelle Baquet	
	French Air Traffic Control
	This is a huge project which is currently under developpment
	where the customer will order 1200 AXP stations running OSF1
	with DECnet/OSI. OSI support was one of their requirement.


. Societe General	Contact Michel Ajzenberg
	Our largest DECnet customer with 20000 PC's and about 1000 VAXes

    
    

	The following mail is posted without the express permission
	of the author, as this could not be obtained at this time.


                  I N T E R O F F I C E   M E M O R A N D U M

                                        Date:     23-Jan-1994 16:54 CET
                                        From:     Jukka SILVENNOINEN @FNO
                                                  SILVENNOINEN.JUKKA AT A1EEMELI at HSKRTR at FNO
                                        Dept:     FN EIS ACT
                                        Tel No:   879-5306

TO:  robert watson@zuo

Subject: I: Decnet/OSI & Finland

		  Bob,

		  sorry for the late answer and silence from 
                  Scandinavia, but I've been off-site most of last 
                  week. And mobile networking does not yet work in 
                  practise  ;-)

		  I totally support your statement on dangers to drop 
                  Decnet-OSI (or even put a message out that this 
                  might happen). In Finland one of our biggest 
                  challenges is to migrate existing VAX customer base 
                  to Alpha. For VAX customers Decnet is the best 
                  integration tool we have, and it is now when 
                  customers start to migrate to Phase V, so smooth 
                  Decnet-VAX transition path is a must. If we force 
                  them to TCP/IP, we might also loose them to 
                  competition.

		  Also, even if government in Finland in practise does 
                  not keep too tight discipline to apply OSI (vs. 
                  TCP/IP), Digital has a good reputation as 'OSI 
                  vendor' and we will be in key position for future IP 
                  integration. We don't want to loose it. 

		  Additionally, telecomm's business (doing quite well 
                  in Finland) will need OSI, since TMN-standards are 
                  more and more applied to network management of 
                  public networks.

		  Best regards

		  Jukka   
    
    

	The following mail is posted without the express permission
	of the author, as this could not be obtained at this time.

                  I N T E R O F F I C E   M E M O R A N D U M

                                        Date:     19-Jan-1994 17:04 CET
                                        From:     BUTTIENS
                                                  BUTTIENS@AMBIS1@BIS7@BRO
                                        Dept:      
                                        Tel No:   DTN 856-7923

TO:  robert watson@zuo

Subject: DECnet/OSI reference list.

Bob,

I fully agree with every feeling and thought expressed in your message.

An important element wich discourages me is the non-availability of popular
environments and applications on top of DECnet/OSI.   You don't buy and
maintain a network for the fun of CLNP or IS-IS or TP4.  You want it for the
services that it offers.   Well, I think that 'copy', 'set host', etc ...
(traditional DECnet applications) aren't good enough.   We are often put into a
very defensive position because of the lack of 'cream' on the cake.

Why don't we have NETBIOS on top of OSI TP4 ?
Why don't we have DECnet/OSI (and autoconfiguration of NSAP's) on (portable)
PC's ???  [ it would put OSI in a very good position versus the cumbersome
address management for IP addresses ]
Why don't we implement SNMP over OSI in all our products (with
autoconfiguration of course  !!) [ SNMP is probabely subject to discussion ]

In general : why does Digital stop when we're almost there ... ?

I don't have a lot of time now, so this should do ...   If you need more
gunpowder, please ask Danny Mylle or myself.

>>    Also - please tell us of any customer's you work with who are active with
>>    DECnet/OSI. The best would be reference sites, but we also need to get a
>>    better feel for the number of active customers. Please update the list at
>>    the end of this mail.

    Additional Customers 'doing something' with DECnet/OSI.

In addition to those of Danny Mylle : 

(Those marked with 'Lux' are customers from Luxembourg)

G�nerale de Banque
PARIBAS
Luxair (Lux)
Cr�dit Professionel du Hainaut
Cimenteries Belges R�unis
Arbed (Lux)
PTT Luxembourg (Lux)
MACH (Lux)
SWIFT

I hope you shoot this into the right direction.   Go for it.

Regards,

/Roger.

	The following mail is posted without the express permission
	of the author, as this could not be obtained at this time.
    
From:	TKTVFS::IDO          "Naoki Ido,CSC/TOKYO,DTN-680-2456" 18-JAN-1994 15:36:07.27
To:	WARNUT::PUNSHON
CC:	IDO
Subj:	RE: UUU: DECnet/OSI in Japan

Hi Ken,

Yes, many customers are already using DECnet/OSI but not large network like 
HEPnet. Most of thoese customer are still using PhaseIV compatible mode
since the routing is still PhaseIV.
    
One of the biggest customer is NTT (Nippon Telphone and Telgraph). They
has deveoped some procurement specification aginst multivendor system
connectivity based on OSI. It is called MIA (Multivendor Information
Architecture). Our DECnet/OSI exactly meets MIA. In other word, MIA
has refered to DECnet/OSI and other OSI products from DEC.
MIA has not completed yet. It's still under development to expand
supporting TP and EDI.
    
NTT is the huge campany. It has many different organizations. If they
or their subsidiary parchase any infromation system then those must
meet MIA standard. So, DECnet/OSI has outdistanced other local vendors in
NTT. Many different organizations in NTT are getting DECnet/OSI now
and these routing domains should be configured eventuary a single domain
in near future.

Regards,
Naoki

    Conclusion:
    
    So, humble apologies for the braindump in the preceeding notes, but
    having arrived here I thought I may as well say what was on my mind.
    
    Incidently I'd have joined in a little earlier is I had not had to
    spend 10 minutes issuing bizarre and weird commands to the DECnet on
    this node to get it to know about HUMANE. First I could not work out
    what HUMANE was down all the time, then I had to work out that we had
    the wrong address [35.813 (HUMANE)], and then after alittle messing
    about I managed to delete the old nodename and get it set correctly.
    
    Of course the Phase Iv alternative to this is to run the several 100
    lines of DCL everynight that copies the worldwide database to the 80K+
    nodes in the network, and then put up with the startup time.
    
    Odd... I've not had to do this for 18 months on my usually system, it
    just seems to know about the nodes right first time and everytime.
    Can't think why..... maybe it's using a distributed node database. That
    would be a nice feature to have in DECnet...
    
         So:
         
         1 - lets work together to ensure DECnet/OSI is good for everyone
             and not just the silent majority.
         
         2 - Lets take account of each other's situations. We need please
             GE just as much as we need to please NTT, Roche, ICI, MCI
             etc.
         
         3 - Lets ensure we understand at least our own product set and
             don;t continue to propogate the FUD in some of the earlier
             notes.
         
         If you have been - thanks for listening
         
         Bob
         
         
         
         
         

    I've hidden .80 through .83 as they are in violation of corporate
    policy regarding posting mail messages in notesfiles without the
    author's permission.  As soon as permission is granted, I'll 
    unhide them.
    
    					Steve

    Matt makes some good points that I'd like to clarify.  We do have
    a finite budget and that budget, (for the OpenVMS product), is tied
    very strongly to new VMS licenses sold.  This obviously is not good
    news for our budget.
    
    DECnet-OSI is a superset of PhaseIV in that it contains all the
    documented programming interfaces, (PhaseIV applications run without
    recompilation), NSP is still a transport layer, and Distance Vector
    is still a supported Routing protocol, (Aka we can still run in a
    PhaseIV area.  So you have to cut support for some of your products,
    one is a superset of the other and brings in new business world wide.
    Please try and understand the Product Management people's dilema here.
    Did I mention that configuration asks 5 questions and does not require
    a server when using the local name space option?  (Sorry if I am 
    repetative but this message is very important.)
    
    It would be incorrect here to conclude that we are writing off our US
    customers.  We are frantically trying to find and remove the barriers
    customers have from migrating to PhaseV.   Our next release, (which we
    hope to have out prior to retirement of PhaseIV), has removal of
    customer migration issues as top priority.  Some of the bigger US
    customers are hedging on moving their networks to OSI or TCPIP.
    We could all benefit from winning a couple of these battles!
    
    I think the discussion to retire or not retire PhaseIV is a very
    important one for this company.  I asked product management if they got
    any feedback as there was some strong opinions voiced here and I was
    interested in some of the results and conclusions.  None...
    
    I don't want to discourage input to product management or to myself
    directly as to what we should do to make this migration easier.  Some
    of the more insulting notes were not constructive.  These notes were 
    heard all right, but the point was lost, (if there even was one.)
    Using that kind of rhetoric does nothing but destroy your own credibility.
    To read about people being laid off today gave me a pit in my stomache, 
    but to read that someone would enjoy seeing someone else laid off made 
    me want to puke.
    
    Things are not going well, let's face it.  If the different groups
    start pointing at each other and saying this group is causing us to
    go down, the battle is lost.  I hope this an isolated incident and
    not a trend in Digital Culture.
    
    Economics may very well dictate the decision to retire PhaseIV over
    the next 18 months.  In that time I encourage you to try the 5.7 kit
    that has just been sent to SSB.  If you find things that are 
    inconvient and need fixing we need to know now.  In addition, you will
    be better equipped to discuss with apprehensive customers their
    concerns.
    
    I was at DECUS in San Francisco.  We did workshops every day at noon
    on installation and configuration.  The feedback was pretty good from
    those that attended.  One customer did not want to do this upgrade
    or any other upgrade and could not wait until the one VAX he had to 
    manage was removed.  That guy wasn't too encouraging.   I don't think
    the PhaseIV vs. V issue was too important to him. 
    
    As to that article;  That guy was in a discussion group at DECUS where 
    we went over the local naming option and how you could run in a PhaseIV 
    routing environment yet he elluded to the fact that everyone would
    need to set up a name space and replace all their routers with PhaseV
    routers!  Man that's frustrating!
    
    Hang in there,
    Pete Carson 
    DECnet-OSI Engineering
                                                     

Paraphrasing somebody or other:  "It's the *CONVERSION*, stupid!"

People (notably those from DECnet/OSI Engineering and Marketing) have been
saying the following:

1) DECnet Phase V is technically superior to DECnet Phase IV

2) The API for Phase IV has been preserved

3) Customers outside of the US are demanding it

4) Nodes on the Easynet have been running some parts of Phase V (notably 
   the Wave-1 code) for a while now, and they plan to migrate the Easynet 
   to Phase V "over time"

5) Conversion of a node is easy (Pete Carson mentioned 5 questions only)


I grant all of the above points.  But they are irrelevant to our customers.  
The bottom line is that

1) Most customers (inside or outside of the US) see no benefit to OSI over
   either DECnet Phase IV or TCP/IP.  Engineers (of which I consider myself
   one) can talk to themselves all they want about technical superiority
   and improvements over other protocols, but most customers don't think
   that DECnet or TCP/IP are broken, so they see no reason to fix it!

   This is not true of all customers, and I grant you that a few of our
   larger customers may have requirements which force them to move to OSI.
   But just because Roche or GE or GM needs OSI, don't force every company
   whose entire network consists of 100 PCs and 1 server to switch to it!
   Because I can guarantee you, they will switch to either IP or Netware.

2) Because they see no benefit, they don't appreciate the *AGONY* of the
   conversion process.  Yes, I only have to answer 5 questions to convert
   a node (according to Pete Carson in .86).  *BUT I HAVE TO ANSWER THOSE 
   SAME 5 QUESTIONS ON EVERY NODE ON MY ENTIRE NETWORK!!!*  And before I am 
   done I have to throw away most of my networking equipment and replace it 
   with other networking equipment (replacing routers with DECnis).

   This is a *major* investment in money and time, and for most customers,
   yields no business benefit whatsoever.

Don't you see?  We are asking customers to throw away working equipment and
software plus their huge investments in training, replace it all with new 
stuff (at a time when most businesses are cutting their capital expenditures),
for no benefit to them as a customer.  And we are surprised when they balk?


RE: .54

>Next summer, these systems will be migrated to DECnet/OSI for OpenVMS V5.7.

Oh?  The conversion to DECnet/OSI is 6 months away?  Deja vu all over again...

>All the routers on EASYnet are being replaced by DECNISes.

What business benefit will Digital see from this conversion?  It will cost
a ton of money (try pricing the conversion at what we would charge our
customers, not at transfer cost).  What is the ROI?

>You can tell your customers that EASYnet is transitionning to DECnet/OSI.
>We will not be completely cut over to DECnet/OSI until quite a long time 
>(actually until DECnet Phase II systems will be retired !), but that is not
>important to the matter... 

That is *exactly* the matter.  We can't do the conversion of our own systems,
and yet we are forcing our customers to convert their systems if they want
to stay with Digital.

>The migration of the production systems to DECnet/VAX Extensions took 2 months.
>Their migration to DECnet/OSI will take 2 months (the preparation of the 
>migration is another story...).

So we took *4 MONTHS* to convert a few systems from Phase IV to Phase V, plus
some (presumably larger) amount of time to prepare for it.  Boy, answering
those 5 questions must be a real killer...

>Yes, EASYnet is late in its migration to DECnet/OSI, but it is happening... You
>can also tell your customer that Digital's network is by far more complex 
>than the average DECnet network and planning its migration is not such an easy
>job. In a few months from now, the bulk of the migration will be behind us. 
>I hope that then, you will let your customer know we made it...

Don't you see that this paragraph negates every statement made about how 
easy the conversion is, and how co-existence is possible?  How this paragraph
(and the experiences which caused it) creates terror in the minds of both
customers and Digital people who are thinking about this conversion?  How
this paragraph causes paroxysms of joy in companies like HP, IBM, Sun, TGV,
Synoptics and others, who can see how their revenue will explode when we
enforce this decision?


RE: .69
    
>    	Or maybe people in the U.S. are ignoring DEC's market, 60% of which
>    is outside the U.S..  To scrap OSI now in favour of TCP/IP would be
>    rather a case of the tail wagging the dog.

No one is proposing scrapping OSI.  We are disagreeing with the decision to
scrap Phase IV!
    

RE: .73 -< Our TCP/IP on VMS *is* getting better >-

>TCP/IP Services for OpenVMS (aka UCX) V3.0 seems to have some nice stuff
>that customers I support have been wanting. It is available on the Alpha now
>and will probably be out for VAX/OpenVMS soon.

I am sorry, but this is way too little way too late.  When the manager of
the UCX group stated that they have fixed the quality problems of V2, I
believed him.  Then I saw my customer crash his system by following the
installation instructions in V3.0a.  We had already recalled V3.0 for quality
problems, and the version we had replaced it with crashed the system during
installation!  What are we up to now, V3.0d?

Fool me once, shame on you.  Fool me twice, shame on me.  I am selling TGV 
Multinet to my customers.  It is available now on OpenVMS VAX and AXP, is
faster than UCX, is *much* more reliable, and offers NFS client support 
(which has been promised in UCX for over 18 months that I have been aware).


RE: .74

>Lastly, every ones budget is being cut.  Now we have the resources to
>either work on 1) Phase IV for about $300 million or 2) Phase V for 
>multiple billions of $$ worth for major SI projects over many numbers
>of years.  Where would *you* focus your efforts?

Oh, I get it.  Conversion from Phase IV to Phase V is so easy that we can
charge customers "multiple billions of $$ worth for major SI projects over
many numbers of years" to help them do it.  Neat trick, to charge them so
much money for answering 5 questions...

You can't have it both ways.  Either the conversion is trivial, or it is
so tough it is worth tons of money in SI projects.


RE: .75

>	- The DECnet program continues to be one of the most profitable
>		programs within Digital

It certainly is.  But notice that all of this money is being charged for
Phase IV, not OSI!

>	- The UCX program continues to grow in profit each year, despite an 
>		overall slowdown or dropoff in VMS system sales.

I disagree with both sides of your statement.  VMS system sales continue
to be the backbone of this company, and UCX is not selling to any customer
that *I* am aware of.


RE: .78

>         - Many of you appear to have very ready access to non-technical notes.
>         How you find the time to do this after working with customers, selling
>         and leading, plus also keeping up technically with the products 
>         (eg DECnet/OSI) so you really understand then, whilst also providing
>         timely and tell thought out feedback to engineering and product
>         management is amazing. You must work very late. Unfortunately many of
>         use are out of the office (on customer site) most of the time and
>         access to US notesfiles in the US daytime (evening in  Europe) is not
>         great.

Notice the time of this note.  Yes, some of us do all of those things, and
still feel strongly enough about Digital and the products and services that
we sell, to put in the time late at night to try and educate people about
the consequences of their decisions.

    		  
RE: .86

>    DECnet-OSI is a superset of PhaseIV in that it contains all the
>    documented programming interfaces, (PhaseIV applications run without
>    recompilation), NSP is still a transport layer, and Distance Vector
>    is still a supported Routing protocol, (Aka we can still run in a
>    PhaseIV area.  So you have to cut support for some of your products,
>    one is a superset of the other and brings in new business world wide.

If it is a proper superset, then everything in Phase IV would work in OSI.
If it "cuts support for some products", then it is not a proper superset.

And I question that it will "bring in new business world wide".  Several
people have made the point (here and through the proper channels) that this
will *LOSE* us some business.

>    It would be incorrect here to conclude that we are writing off our US
>    customers.  We are frantically trying to find and remove the barriers
>    customers have from migrating to PhaseV.   Our next release, (which we
>    hope to have out prior to retirement of PhaseIV), has removal of
>    customer migration issues as top priority.  

Don't you see that "removing the customer migration issues" is a prerequisite
to retiring Phase IV?  How can anyone conceive of retiring something and then
promising that sometime in the future we will show you how to do the migration?

I say this again:  Until the *ENTIRE* Easynet is converted to OSI, and *EVERY*
single minor bug has been worked out of the conversion process, you must keep
Phase IV fully supported.  The marketing campaign that you could build around
the successful conversion of the massive/complex Easynet would be absolutely
marvelous.  But the FUD that our competitors are spreading, based on our
inability to convert the Easynet, is killing us.

>						  Some of the bigger US
>    customers are hedging on moving their networks to OSI or TCPIP.

Ever wonder why?
    
>    Economics may very well dictate the decision to retire PhaseIV over
>    the next 18 months.  In that time I encourage you to try the 5.7 kit
>    that has just been sent to SSB.  If you find things that are 
>    inconvient and need fixing we need to know now.  

But it is *TOO LATE* then.  The kit is in SSB!  If we find problems, we 
will have to wait months or years for a fix, and meanwhile our customers
will not be able to purchase the latest Digital processors, because the
version of the OS which supports them requires OSI...


I am trying to be constructive.  I don't want to kill OSI, I recognize
the requirement for it.  But by the same token, I don't want to kill
Phase IV either!

-- Ken Moreau

    I have friends and associates who were laid off Monday.
    
    NETwork associates who the company doesn't see a need for
    (too much DECnet expertise)...
    
    Next it will be VMS associates because the management team 
    believes that VAXsales are declining because VAX sales
    didn't meet the imagined forcast.
    
    Then we can go after some real fat...
    
    
    --
    Don't shoot me here... I'm just a delivery boy...
    
    There is no time for this type of discussion, it would be more 
    productive to find something customers want to buy (and not buy 
    as a bundled package like DECnet has always been) and start selling it.
    
    
    
    Points:
    
    UCX continues to crash my customers systems with alarming 
    regularity. CSC team seems to know the patches by heart 
    -- Everyone knows someone who's system has been destroyed by UCX.. 
    Nice reputation to try and come back from in a commodity market...
    
    Arguing in an Easynet Notesfile about DECnet/OSI brings us
    no closer to gaining any acceptance in the market.  The market
    is convinced about TCP/IP and sees little differenciation
    between DECnet/OSI and TCP/IP functionality for the basic things 
    they want to do with the products (virtual terminal, file 
    transfer, remote directory services, task to task objects for 
    programming, E-mail, Xwindow transport)
    
    DEC groups always touts our fine engineering, to many people in 
    the market for a Chevrolet solution(and budget), we offer a Rolls 
    Royce with assorted options "ALL" included at "ONE" high price 
    (in the customer's view).
    
    
    --
    DECouple the networking and the OS for both OpenVMS and offer 
    customers the choice of networks TCP/IP or DECnet... I'd wager
    most new systems would go out with TCP/IP only...
    
    
    If I've said some things to get the networks people hot, it wasn't 
    for naught,  because I've received the best arguments and summary 
    of "WHY DECNET/OSI" instead of TCP/IP. 
    
    This will help me in my customer dealings and to present the 
    "Corporate line" much better to the public but one has to ask:
    
    Why haven't I seen this in print, Internet, and on the lips of every 
    DEC employee?  (Could it be that the OSI team cried wolf once too 
    often and folks just aren't paying attention anymore? My customers 
    started going ballistic about the Digital Review article about Phase 
    IV support going away after OpenVMS 6.1)
    
    Why do our customers believe TCP/IP is the way, the light and the
    promise?
    
    I put it to you that TCP/IP vendors and suppliers have captured 
    the imagination of the industry and the only way that we could 
    even attempt an assult with DECnet/OSI is to provide a concerted 
    marketing campagin to both our customers and potential customers.
    
    Me trying to sell DECnet/OSI will require a lot of education for 
    not only our installed customer base but anyone who already has a 
    TCP/IP network.  Sales margins won't allow for that amount of time
    to be spent anymore on commodity sales.
    
    
    --
    So you folks win.  DECnet/OSI is technically superior to any
    other networking protocol on the market today and will provide 
    exceptionally flexible service for years to come...
    
    Tell me how to convey that truth and make it important enough to 
    a customer to buy it with less than 1000 nodes who only want File 
    transfer, Virtual terminals, Remote Disk sharing and E-mail...
    
    Tell me how do do that in the 5 minute part of a sales call 
    relegated to the "Do you have TCP/IP support? So you fit into 
    the rest of my network." part of the conversation...
    
    
    --
    Once again the Earlier remarks were to provoke, thank you for your
    attention these past few days some of your points are well taken
    and some of them are out of touch but please understand my purpose
    was to touch a nerve that seemed deadened by at least 7 years of angst.
    
    
    IMHO to get DECnet/OSI accepted in my customer's sites will be a 
    tough sell, more so when they demand TCP/IP up front..
    
    USEnet posters may not be representative of our customers but 
    note the ratio of 3% posters to 97% lurkers in any newsgroup... What 
    is posted there goes on the lips of most of my customers as tough 
    questions in the "Stump the DECie" game.
    
    You want to start Damage control for DECnet/OSI .. Start there 
    and not in an Easynet notefile...
    
    John Wisniewski

    	We seem to have four classes of customers :-
    
    1) Those that are not prepared to take the cost of answering the five
    questions across all their nodes. Since this is less than the number of
    questions answered in a VMS upgrade or an NT installation they will
    presumably be sticking with their current systems "forever". This is a
    quite viable solution. I have heard of one customer who is still
    running VMS V1.6 on his VAX-11/780 and is very happy with it. The only
    thing we will sell to these customers is maintenance contracts.
    
    2) Those who want to move to TCP/IP. It is not clear whether this is
    because it can be done with less than 5 questions, but it is clear that
    it is almost exclusively a US phenomenon.
    
    3) Those who are quite happy to answer the five questions for benefits
    the upgrade may give them.
    
    4) New markets. Specifically: 
    Eastern Europe plus Russia and Ukraine are about the same population as 
    the EEC (1.5 times the population of the US) and they are in much the 
    same position as post-war West Germany. That is, they have *no* 
    legacy systems and are not interested in buying obselete technology 
    like TCP/IP.
    Japan, population 0.5 times the population of the US, decided on OSI, 
    and opening up trade barriers.
    China, population 3 times that of the US, no legacy systems. I know
    nothing detailed about the market, but I would expect them to be doing
    much the same as Eastern Europe.
    
    	In summary, assuming *nobody* in the U.S. buys OSI then currently
    we are satisfying all our actual and potential customers (ignoring
    comments about product quality of UCX) because Phase IV is still
    supported; in a few years 80% of the world market will probably be OSI,
    and the US will be a mixture of TCP/IP and Phase IV customers who (like
    our customer with VMS 1.6) decided that the upgrade wasn't worth it.
    
    	Given that we have a limited engineering budget would you spend it
    on TCP/IP, OSI, or Phase IV?
    
    	To return the provocation in kind, if we can get a significant
    proportion of that 80% world market then we can probably afford to
    support our US sales and technical support colleagues with their
    interests in TCP/IP as dead wood in the company.

    .87
    	Ken, I do agree with alot of your points and believe me there
    are some tough decisions being made here, I'm glad I don't have to make 
    them.
    
    	Please understand that the migration of the easynet and purchase
    of several DECnis's to move the L2 backbone to Linkstate is a different
    issue than upgrading individual end nodes.  The decision to upgrade 
    the easynet, (too late, I'll grant you), is based on the number of
    nodes in our network exceeding the PhaseIV address space.   Our 
    customers do not have to replace their routers to upgrade individual
    end nodes.  Note that TCPIP has a limited address space that can 
    easily be fixed by moving to CLNS with the OSI addressing space.  I
    spoke to a customer at DECUS who wanted an address for each residence
    in the US to allow him to address individual utility boxes.  He wanted
    IP addresses and they laughed at him.  This is trivial with OSI.
    You apply for an IDP and the phone nmberes for each house becomes the 
    address.  Done.  He was upset that we were not doing a better job
    in martketting the benefits of OSI.
    
    	Our PhaseIV code base is an extremely reliable and mature product
    and I don't blame customers who bet their business on it being
    reluctant to discard this.
    
    > Paraphrasing somebody or other:  "It's the *CONVERSION*, stupid!"
    
    	No, it's the money.  What drives this is money and it had better
    be.  Customers are angry at DEC and it frustrates me just  as much as
    you.  Unfortunately, we need to make some difficult trade offs with
    limited resources.  What pisses our customers off most is 20 dec people
    they speak with each leading them in a different direction.
    
    Let me ask you this.  Is PhaseIV winning contracts in sites that are
    saying TCPIP is our future?
                                                                  

    My $0.01:
    
    I've seen a number of RFI's from large financial institutions
    (mainly banks and insurance companies) here in Europe for the
    last few years. Generally TCP/IP is mentioned if anything. I've
    yet to see one with OSI requirements.
    
    But maybe I've been getting the wrong RFI's :-)
    
    Anyhow just to put the "Europe wants OSI" theory into a little
    more perspective..
    
    re roelof
              

    Frankly, I don't see much RFPs with just OSI. most common are
    multiprotocol backbones with minority DECnet/OSI traffic, most TCP/IP.

    But during Network Academy we were told that DEC has answered to multi
    bill. $ RPFs of OSI in gov. market . European Community now will
    require OSI for all gov. purchases , there are some recent laws passed
    about it. So there is a multibillion $ OSI market.

    The real change is to multiprotocol networks not TCP/IP rather then OSI.

    IP has won the network management , this is done deal, over. There are SNMP
    MIBS for 10k+ pieces of equipment . All new great DEC comms gear is
    SNMP. So, independently what anybody thinks, this is the way world has
    gone. Even pure OSI/DECnet end-system networks will need SNMP for
    management.

    Anybody thinking about buying any new comms equipment will take that
    into account. 

I've been following this note with interest and would like to add an 
internal customers viewpoint.


There is a plan well advanced in WW IM&T to move to OSF and TCP/IP. Why?
Because we are buying applications from third parties to support our Order 
Admin., Tele-sales, Fulfillment and possibly materials management and 
finance which require TCP/IP.

Customers don't want networks anymore than I want fuel oil. What I want is 
heat, oil is my selected alternative.  Customers want certain business 
functions a.k.a. applications. They will choose a network product based on 
their application set.

Of the large application houses I've looked at, I've seen none that won't 
support a TCP/IP network (assuming they support any at all).


Oh, BTW, those applications we're buying?  The two big ones come from 
Europe, R/3 from SAP and POINT.

RE: .87
>>    Economics may very well dictate the decision to retire PhaseIV over
>>    the next 18 months.  In that time I encourage you to try the 5.7 kit
>>    that has just been sent to SSB.  If you find things that are 
>>    inconvient and need fixing we need to know now.  

>But it is *TOO LATE* then.  The kit is in SSB!  If we find problems, we 
>will have to wait months or years for a fix, and meanwhile our customers
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^      
>will not be able to purchase the latest Digital processors, because the
>version of the OS which supports them requires OSI...

This is plain wrong, and I can't let it pass.

Properly escalated calls to DECnet engineering get immediate attention, with
fixes available in a matter of days, not "months or years." If the field would
"properly escalate" the calls to begin with, it wouldn't take so long. I get
several CLD's a month without the supporting information, like a crash dump,
error logs, operator logs, nettraces, or even a description of how to recreate
the problem.

Please get your facts straight instead of relying on emotion to make your points.

RE: .88

>    I have friends and associates who were laid off Monday.

I'm truly sorry to hear that.
    
>    NETwork associates who the company doesn't see a need for
>    (too much DECnet expertise)...
>    
>    Next it will be VMS associates because the management team 
>    believes that VAXsales are declining because VAX sales
>    didn't meet the imagined forcast.
>    
>    Then we can go after some real fat...

I'm sure this will start a flame-fest, but it needs to be said.

I don't think anyone believes that their management does the right thing when
someone gets laid off. BUT...

I was out at a major customer site last year. While I was there, there were two
Digital Consultants working for this customer. The customer was very pleased
with these consultants, who were continually suggesting to the customer how to
improve their applications and operations.

There were also two other Digital Consultants who weren't currently on any
contract. They spent the day reading the paper, drinking coffee with the
management, reading notes files and Usenet News. Literally.

Guess which two got laid off?

The two on the contract. They walked out of the office on Friday at 2:00 and
went down the street to a contract agency. Monday morning came, and the customer
started yelling at Digital at their Monday morning meeting, claiming that
Digital had violated their contract by changing their personnel without warning,
and that noone was there on Monday, all in violation of the contract. When the
local office couldn't supply someone that day, the customer broke the contract
and in walked the two ex-DEC employees to do the same job at 3 times the salary. 

DEC lost that contract, worth 400K/year and GAVE it away.

Layoffs are tough for everyone, but I don't think anyone believes that they are
all being done correctly.

Regards,
Bryan

    This might be slightly off the thread of discussion, but here is my
    perspective:
    
    Without DECnet/OSI we would be unable to communicate to Siemens
    shop-floor controllers. Siemens, along with Allen-Bradley, have the
    highest market-share world-wide for PLC's (Programmable Logic
    Controllers).
    
    Without the ability to provide these connections we would lose sales of
    Digital's computers into this market place. We would probably also have
    major difficulties in untertaking systems integration projects of this
    type i.e. we would lose consulting revenue. DECnet Phase IV is just not
    enough for our needs. We also often need a mixed TCP/IP and OSI
    environment. So it wouldn't help us to only have TCP/IP available.
    
    Thank you DECnet/OSI. You are contributing to keeping a number of my
    colleagues in a job, at least in Europe, if not world-wide. 
    
    Mike
                                                                      

re; .90

Pete, thank you for taking my (sometimes volatile) feedback in the manner in
which it was intended: as a plea for understanding from someone who (like 
most if not all of the contributors) wants Digital to succeed and make all
of our stock-holders rich...

>						The decision to upgrade 
>    the easynet, (too late, I'll grant you), is based on the number of
>    nodes in our network exceeding the PhaseIV address space.   

No one is arguing that Phase IV has technical limitations which will force
some number of customers (and Digital) to an OSI world.  What I am trying
to say is that the limitations are not evident to many customers, and so
they do not see a need to move.

>			He was upset that we were not doing a better job
>    in martketting the benefits of OSI.

*Amen* to that.  Digital marketing of everything is extremely poor, but our
marketing of OSI borders on criminal.
    
>    > Paraphrasing somebody or other:  "It's the *CONVERSION*, stupid!"
>    
>    	No, it's the money.  What drives this is money and it had better be.

We are in violent agreement.  The conversion effort is painful to customers
because it costs them money, both in new network hardware and in dedicating
very expensive people to this task instead of some other more productive task.

    
>    Let me ask you this.  Is PhaseIV winning contracts in sites that are
>    saying TCPIP is our future?
                                                                  
No, you are right there.  Almost every customer I know of says that they will
eventually consider OSI, but for right now they are switching almost everything
to TCP/IP.  

But I am not saying that Phase IV will win us new customers.  I am *definitely*
saying that removing Phase IV from our product set will *lose* us customers.

-- Ken Moreau

I appreciate the fact that many people are concerned about the recent 
announcement that DECnet/OSI will replace DECnet-VAX in OpenVMS V6.2 - 
approximately 18 months from now. I also appreciate the fact that many 
individuals have presented clear and articulate notes regarding the 
impact of this announcment. I am however concerned that many of the 
arguements presented are based on information that is now three to five years 
out of date. The most current information has been presented in many 
notes (thank you all!) although there is still a strong current of 
disbelief.

For those who are not convinced by words, I suggest that you install
DECnet/OSI on a local system and use it for a while. I believe you
will be surprised to find that the installation is easy, that the
DECnet applications will continue to run and that the Phase IV routers
will continue to accept your data packets. If your experience is
otherwise, please let me know - I am always looking for constructive
feedback. 

Fact: DECnet/OSI is both DECnet and OSI. It is not just OSI, nor are
we in any way trying to "ram OSI down our customers throats". What we
are doing is shipping a new version of an existing product that
provides full compatibility with the old version as well as
enhancements as well as an additional protocol stack. As with standard
industry practice, new versions of products render the old versions
obsolete. Customers decide whether to upgrade to the new version, stay
with the old version or go elsewhere. Ideally, this decision is based
on facts and not on emotion. 

Fact: The conversion/transition/migration from DECnet-VAX to
DECnet/OSI is not an agonizing process. It does not have to happen
everywhere overnight nor does it require a complete overhaul of
existing hardware. The built-in backwards compatibility allows for a
gradual evolution from the old version to the new. The bulk of
networking equipment in networks today will continue to work - any
system supporting OpenVMS also supports DECnet/OSI and DECnet/OSI can
work with existing Phase IV routers. The existing applications
continue to run unchanged. End users will not have to be retrained -
most don't even realize the network software has been upgraded. The
level of investment is extremely small - especially when compared to
the level of investment required to move from DECnet-VAX to TCP/IP.
(This is not to say that customers choosing to move to TCP/IP are
doing the wrong thing - I just hope that they are doing it for the
right reasons and are fully aware of what needs to happen to meet
their goals). 

The EASYnet has been migrating nodes to DECnet/OSI for some time now -
the European EASYnet will complete their migration by the end of the
year. The US is moving forward as well. Note that the EASYnet, like
most networks today, will not be 100% anything - the EASYnet supports
DECnet, OSI, TCP/IP, SNA, IPX, Appletalk and likely a few more as
well. 

The reality is that network managers today are caught in chaos. The
pace of technological change is very fast and that can be either
exhilarating or frightening. In either case, network managers need
facts in order to make decisions affecting their networks and their
end users. They are receiving requests from all directions and are
trying hard to reconcile the variety of network infrastructures
required to satisfy all requests - from X.400 mail to PC applications
to VMS-based applications to IBM/SNA based databases. The reality is
that networks today are multiprotocol - OSI, TCP/IP, DECnet, SNA, IPX,
Appletalk, Vines, all have their place and will be in the network for
many years to come. No one network protocol has won the distinction of
being able to provide for all the needs of all the end users. Each has
its good points and bad points and each is constantly working on
improvements - witness the work being done by the IETF to improve
TCP/IP, and the continuing work on OSI standards. 

Customers want open networking options. DECnet-VAX does not provide
any options other than DECnet. DECnet/OSI provides the options of
DECnet and OSI on OpenVMS platforms (with plans for TCP/IP); DECnet,
OSI and TCP/IP on OSF/1 platforms. The customers have a base from
which they can move forward to open networks while still using their
older applications. 

Digital has the networking expertise to provide all the help our
customers need. Digital also has a wide-ranging portfolio of
networking products. While there may not be a full Digital solution to
all the problems customers face, there is the knowledge base in this
company to recommend and advise them on solutions. Given facts instead
of emotion, customers can make the correct decisions for their own
situation (which could very well include a lot of Digital product). 

Judy Cross
DECnet/OSI for OpenVMS Product Manager

    Most of my 15 years with the company have been devoted to the field of
    communications - both DECnet and TCP/IP.  I have considered myself to
    be unbiased with respect to the superiority of one vs. the other.  I
    happen to work on TCP/IP for the past two years, and I find some of
    this conversation typical of our traditional corporate bias.
    
    I think this string is exemplary in some respects of the type of
    inbreeding that our communications product strategy has suffered from
    in the recent past, and perhaps it gives some indication of the need
    within our own organization to open our eyes to the real world. 
    We accept TCP/IP only grudgingly, despite the fact that every time we
    produce a TCP/IP product, we make a forture on it.  Go figure.
    Specifically:
    
    Re: .88
>The market
>    is convinced about TCP/IP and sees little differenciation
>    between DECnet/OSI and TCP/IP functionality for the basic things 
>    they want to do with the products (virtual terminal, file 
>    transfer, remote directory services, task to task objects for 
>    programming, E-mail, Xwindow transport)
    
    I think this is a gross over-simplification.  The more familiar you
    become with TCP/IP, the more you realize that it is a far more mature
    protocol suite with far more functionality available as a result.  Yes,
    there is a common thread of core functionality, but TCP/IP goes well
    beyond that, simply because it has been around so much longer.  It's
    just a fact of life, without being aware of which shows just how out of
    touch with reality we really are...I mean, over 15 million hosts can't
    be wrong, huh?
    
>    Why do our customers believe TCP/IP is the way, the light and the
>    promise?
    
    This should be obvious.  Because it meets their needs, pure and simple. 
    Apparently, nothing else comes close, yet.  Why is this so complicated?
    
>    UCX continues to crash my customers systems with alarming 
>    regularity. CSC team seems to know the patches by heart 
>    -- Everyone knows someone who's system has been destroyed by UCX.. 
>    Nice reputation to try and come back from in a commodity market...
    
    Now, this is a cheap shot, irresponsible and unprofessional, IMHO. 
    
    First of all, if your customer is having such severe problems, send me
    their name and number, and we'll have them up and running immediately. 
    Spare us the cheap shots.
    
    This is not the place to denegrate our own products, particularly when
    every indication within this very conversation indicates that UCX is a
    primary, growth product for us.  It's already in the top Five software
    products, three of which SHIP WITH THE HARDWARE (including DECnet). 
    The fact that the CSC knows the patches by heart might just mean that
    they know what they're doing - and I applaud their hard work to come up
    to speed.  Yes, the product has had severe problems, but if you look at
    the political environment in which it has been developed, it's no
    wonder that funding and staffing would be stretched to the limits. 
    Care to compare the staffing levels between UCX and DECnet/OSI of late?
    
    The fact is, TCP/IP is a big part of our future, simply because it is a
    big part of the future of computers, worldwide.    Get used to it -
    accept it, and abandon the biases that we have engendered internally
    since the conception of our own, proprietary, DECnet architecture.  So
    long as we continue in denial of reality, we are missing the (revenue)
    boat.  We're in this for the money, not religious protocol wars. 
    Follow the market, respond appropriately, support our customers demands
    - TCP/IP is one of them - OSI is too, but let's get on an even keel,
    shall we?
    
    Tim Grady
    DEC TCP/IP Services for OpenVMS Engineering
    

We are seeing more of the people with authority and responsibility for these
decisions joining this discussion.  Welcome!  Let us hope that we can each
provide some information the other does not have...

RE: .89

>    	We seem to have four classes of customers :-
>    
>    1) Those that are not prepared to take the cost of answering the five
>    questions across all their nodes. Since this is less than the number of
>    questions answered in a VMS upgrade or an NT installation they will
>    presumably be sticking with their current systems "forever". 

There is a difference:  the customer chose to spend time/money on those
upgrades because they perceive a high return on that investment (ROI).  The
customers that I have talked to perceive no such ROI for OSI.  If you can
show me that there are in fact solid business reasons the customer should
convert, please share them with all of us.  I promise that I will convey
these to my customers with all of my ability.

    
>    	Given that we have a limited engineering budget would you spend it
>    on TCP/IP, OSI, or Phase IV?

Again this false-hood is raised.  Read my typing:  *NO ONE IS PROPOSING NOT 
DOING OSI!!!*.  We absolutely must do OSI for the reasons you (and others in
this string) gave.  What is under discussion is abandoning Phase IV, and
the loss of business that it would cause.  Again, this is not a technology
question, it is a simple business decision for Digital:  Should we stop 
funding a product which is one of the largest money-makers for this company,
for which many of our customers have committed major resources, and which 
would cause many customers to leave Digital if we abandon it?
    
RE: .95

>Properly escalated calls to DECnet engineering get immediate attention, with
>fixes available in a matter of days, not "months or years." 

Ok, tell me the channel by which I can report the lack of X.25, P.S.I. and WAN
drivers in OpenVMS V6.0 under Phase IV, and get it fixed in a matter of days...

This is not intended as a cheap shot.  It is intended to show that all too
often Engineering is not *able* (even though they try to perform major miracles
on a daily basis) to deliver the "fixes" that are demanded by our customers.

The customers consider the lack of WAN drivers as a *bug*.  They want it
fixed *now*.  Engineering (because of decisions above them) is not able to
fix this "bug" in a matter of days.


RE: .99

>    I think this string is exemplary in some respects of the type of
>    inbreeding that our communications product strategy has suffered from
>    in the recent past, and perhaps it gives some indication of the need
>    within our own organization to open our eyes to the real world. 
>    We accept TCP/IP only grudgingly, despite the fact that every time we
>    produce a TCP/IP product, we make a forture on it.  Go figure.

I don't know what note string you are reading, but after reviewing all
99 replies, I cannot find any in which "we accept TCP/IP only grudgingly".
Almost every note (including those from OSI Engineering) makes the point
repeatedly that TCP/IP is a major part of the networking world, and that
Digital is a strong player in that world.
    
>>    UCX continues to crash my customers systems with alarming 
>>    regularity. CSC team seems to know the patches by heart 
>>    -- Everyone knows someone who's system has been destroyed by UCX.. 
>>    Nice reputation to try and come back from in a commodity market...
>    
>    Now, this is a cheap shot, irresponsible and unprofessional, IMHO. 
    
My customer had those exact problems.  They solved them by returning all
of their UCX licenses to Digital.  Fortunately they allowed us to sell them
TGV Multinet, so at least Digital made a few bucks on the deal.

This is not a cheap shot, this is a statement of fact.  My customers are
voting with their checkbooks, and the vote is overwhelmingly against UCX.

>    The fact is, TCP/IP is a big part of our future, simply because it is a
>    big part of the future of computers, worldwide.    Get used to it -
>    accept it, and abandon the biases that we have engendered internally
>    since the conception of our own, proprietary, DECnet architecture.  So
>    long as we continue in denial of reality, we are missing the (revenue)
>    boat.  We're in this for the money, not religious protocol wars. 

Absolutely.  Now that Sales Support (again) reports to Sales Managers (a
decision I applaud, BTW), my mind is focused on the money.  And in trying 
to increase revenue and decrease Sales Support time, I recommend TGV.

You say that Digital cannot support the Engineering resources for Phase IV, 
Phase V, and TCP/IP?  If we have to cut somebody (and I accept the assertion 
that we have to), let's make the right decision based on sound business 
forecasts.  Given that, I recommend that instead of cutting the Phase IV 
resources, we should cut the UCX resources.  Go directly to TGV, license
the product, and sell the heck out of it.  TGV gets more sales people
selling their product, and Digital gets a high quality full functionality 
TCP/IP product for no engineering costs.

Again, this is not intended as a shot at any individual.  Digital is making
some agonizing choices, involving pain for many people.  But let us make 
sure that we do the right thing to return this company to profitability.

-- Ken Moreau

    RE .-1

    Ken,

    I think your note is disingenuous. You basically put up a straw horse
    argument that DECnet/OSI is "OSI" then say customers don't want "OSI"
    therefore they don't want the "DECnet/OSI" product and because the
    Phase IV DECnet code will be retired the customer is up shit creek.
    
    All very logical but the basis of your argument is WRONG.
    The product that is called "DECnet/OSI" is a reimplementation of the
    the DECnet product you know and love (referred to as Phase IV in most
    notes). It is basically Vn+1 of the DECnet product. Yes I agree it has
    a lot of "OSI" features over and above Phase IV but that it is
    IRRELEVENT to this discussion.
    
    As with all products when Vn+1 comes out Vn is RETIRED after a certain
    amount of time. If we follow your logic we should still be fully
    supporting V4.7 of VMS.
    
    As pointed out many times installing DECnet/OSI is SIMPLE. Answer 5
    questions. You end up with what you had before. If it is not backwards
    compatible then engineering will fix it. But what DECnet engineering is
    saying is that WAVE3 (V5.7) is of a high quality and they think they've
    fixed all the backwards incompatibility problems.
    
    Often in product development an engineering group decides to
    reimplement part or all of a product to add new features. THis is just
    good engineering. Part of the absolute requirements of this process isd
    maintaining backwards compatibility. The DECnet folks have done this.
    
    Now I challenge anybody to name things that are not backwards
    compatible. I can only think of one that matters:
    
    1, Installing DECnet/OSI breaks cluster alias. To maintain cluster
       alias 1 or more routers on the LAN need to be upgraded or replaced
       to support Phase V protocols.
    
    I admit that this is a problem. I personally consider this a screwup by
    the engineering group. I sincerely hope that this problem is fixed
    (Judy are you listening?).
    
    2, The management utility is NCL and not NCP.
    
    I don't consider this a problem. You really don't need to use any
    management utility to managed DECnet on an end node. And even if you do
    there is now pretty good help on NCL. Also there are plenty of other
    precidents of changing management interfaces as products evolve.
    
    3, I can't think of any more possibilities. If you can list them and
       hopefully someone can address them.
    
    I say we should tell customers that DECnet/OSI is just the next version
    of the DECnet product. All your applications will continue to work.
    Yes there are a load of new OSI features but if you don't want them
    ignore them and don't use them. By default they aren't installed
    anyway. Oh and TCP/IP, yes we support that too. If you want it we'll be
    happy to sell it to you (no I won't comment on the UCX, TGV sub
    debate). So we can offer cusomers what they want. Continue to use
    DECnet and/or use TCP/IP. Don't let the name of DECnet/OSI confuse you.
    It is DECnet PLUS more.
    
    Also I see a lot of people confusing the issue of installing DECnet/OSI
    on end nodes with upgrading their network infrastructure. These are
    TOTALLY independent issues and should not be linked or confused with
    each other. Of course we are letting our competition do just that.
    As I hinted above unfortunately the cluster alias issue does link these
    issues a bit. I truly hope that the DECnet group fix this problem.
    
    When customers hear we haven't upgraded EASYNET to Phase V yet in total
    they need to be told that this is the NETWORK INFRASTRUCTURE upgrade
    issue and NOT the end node upgrade issue to DECnet/OSI. That is just
    updated as and when new versions of O/Ss and products (INCLUDING
    DECnet) are applied.
    
    Dave

    With all due respect to all competent engineers participating in this
    discussion, there is a large area of professional activity that you
    have a very vague idea about, and this is network operations.

    Migration is expensive just as any upgrade of OS is expensive. You do
    it only for good reasons. If this is getting new processor support or
    new software, it can be justified. You might want to upgrade because
    vendor tells you to only if that vendor controls the market.

    What happens now is that customers upgrade or already run
    multiprotocol backbones. TCP/IP is there and is growing. Now we tell
    them that they will have to upgrade phase IV nodes within 2-3 years 
    to phase V if they want to get new processor support or stay supported.
    If you have to migrate , you look around , where is my future ? 
    Even if migration to TCP is technically more expensive, maybe it's
    worth it. 
    
    A sound business decision should be based on numbers, now that
    licenses will be separated, maybe a more clear picture will emerge.

    And if really phase IV product is profitable, why not look at it as we
    look of any other protocol we need to support.

    					wlodek

    re: .100
	Given that, I recommend that instead of cutting the Phase IV 
resources, we should cut the UCX resources.  Go directly to TGV, license
the product, and sell the heck out of it.  TGV gets more sales people
selling their product, and Digital gets a high quality full functionality 
TCP/IP product for no engineering costs.
    
    Digital already has what appears to me to be a high quality full
    functionality TCP/IP product, known as ANET+. Unfortunately it
    was 'not invented here'; ie for some reason the DEC Japan folk
    are not allowed to make it available world-wide. (BTW, they 
    already have it running on VAX/VMS V6 and on AXP/VMS, too)
    
    re: .101 (?)
    
    Besides the Phase IV cluster alias issue, I also see the 150 node
    limit on the Local naming option to be a problem; should have been 
    at least 1024 to allow a full decnet Phase IV area namespace.
    
    Dave

    Re: .98:
    
       I don't want to get too involved in the discussion here, but let me
    just say this.
    
       I'm a fairly experienced engineer-type, and I was able to figure out
    how to configure and manage both DECnet Phase IV and TCP/IP
    configurations without too much difficulty.
    
       I installed DECnet/OSI Wave 3 on VAX/VMS.  After a few months of
    crashes and lack of being able to get anything done, I re-installed VMS
    from scratch in order to get rid of it.
    
       I'm sorry I didn't QAR every problem and issue I had, but I haven't
    had enough time lately to do such things; I need software which lets me
    get my job done as cost-effectively as possible.  Installing DECnet/OSI
    Wave 3 was a disaster.
    
    						-mjg (a happy UCX and
    							DECnet Phase IV
    							user)

    When I read these replies I try to read what people mean, and not be
    overly literal about the words being used.  Having said that, it
    *still* seems to me that people actually believe we are getting rid of
    Phase IV.  Who ever said we are getting rid of Phase IV?  I think
    people actually believe that the Phase IV protocols are being retired. 
    This blows my mind.  All that will eventually be retired is an older
    version of DECnet, because we have a new version to replace it.
    
    DECnet Phase V *IS* DECnet Phase IV (with a little OSI thrown in).
    
    

>Ok, tell me the channel by which I can report the lack of X.25, P.S.I. and WAN
>drivers in OpenVMS V6.0 under Phase IV, and get it fixed in a matter of days...

	It would have been usual to issue at least new versions of
	this software for a major operating system upgrade. So rather
	than having to re-install new point releases of PSI and
	WANDD, why not just install DECnet/OSI V5.7? ( Which is
	available in a matter of a few weeks ...).

    Re: .103
    
>	Given that, I recommend that instead of cutting the Phase IV 
>resources, we should cut the UCX resources.  Go directly to TGV, license
>the product, and sell the heck out of it.  TGV gets more sales people
>selling their product, and Digital gets a high quality full functionality 
>TCP/IP product for no engineering costs.
    
    I don't think you're aware of the whole picture, here.  Are you aware that 
    TGV is the number TWO TCP/IP vendor on VMS?  UCX has a larger market 
    share...the largest.
    
    And has it occurred to you just how much it might cost to buy TGV's
    Multinet?  And to re-train our support people?  Tens of millions...
    
    Furthermore, has it occurred to you that it might make the most sense
    to finally endorse our own TCP/IP product, and provide real corporate
    support, i.e. funding, instead of the minimal funding that the product
    has always suffered with?
    
    Apparently not.
    
    Suggesting the ellimination of yet another highly profitable product in 
    favor of buying out a third party is hardly an intelligent option at this 
    point.  Are you aware that UCX revenue's are astronomical, and the revenue
    per-engineer is in the millions?  Yes, plural, millionS.
    
    The expense and effort required to fix the few problems in UCX is far
    less than what you suggest - I would suggest that you understand more
    of the story before suggesting that we shoot ourselves in the (revenue)
    foot yet again.
    
    tim

    Re: .100
>This is not a cheap shot, this is a statement of fact.  My customers are
>voting with their checkbooks, and the vote is overwhelmingly against UCX.
    
    It's no wonder, since their local DEC 'technical support' is pushing
    our competition's product.  Incidentally, I came from the Florida
    District, I know your customers, I was your predecessor down there.  If
    they're voting against UCX, then you're encouraging them to take
    revenues out of our own pocket.
    
>And in trying 
>to increase revenue and decrease Sales Support time, I recommend TGV.
    
    ...you are, if anything, decreasing revenue...and incidentally, do you
    know how TGV provides worldwide support for your major customers (let's
    see, GTE, Martin Marrietta, Tropicana, you know, those global companies
    you support)?  They don't.  I suggest you re-think your strategy of
    increasing revenues and decreasing support time.  We're kicking their
    butts on support - which you would have heard about if you had had the
    chance to go to either of the last two DECUS's, as  I did.
    
    If we do what you suggest, we'll save a couple million on engineering
    costs, but lose twenty times that much in annual revenue that UCX
    generates...yes, TWENTY TIMES that much...and incidentally, I'm sure
    that licensing Multinet will cost a bundle.
    
    Think about it the next time you recommend the competitor's product
    over our own.
    
    tim
    

I'm running DECnet/OSI.  I have no idea whether I'm using
"DECnet" or "OSI" to write this note today, and what's more I
don't care.

(I could find out with one NCL command if I did care - at least,
 I could find out which transport protocol I'm using, which seems
 to be the common idea about whether it's "DECnet" or "OSI")

    �Think about it the next time you recommend the competitor's product
    �over our own.
    
    Last year, I just recommended that we withdraw UCX and replace it with
    Multinet for a dual-host VMScluster NFS-serving 60 UNIX workstations.
    
    Do you think I did it with joy and glee? A smile on my face and a
    tapping in my feet?
    
    It pains me to have to admit that another company's product has more
    feature than our own, and in this case, the feature that matters. And
    Multinet costs more than UCX. We had to absorb the loss.
    
    Why did I do it (not that I have a choice)? If I had not, we'd lose A
    LOT MORE when we get our entire $1M solution thrown out, slapped with a
    liability clause, and the bad reputation to boot. I'd also have damaged
    a very supportive customer's career who no doubt will continue to give
    us future business.
    
    My point being, people don't sell competitors' products for the hell of
    it. Most often it is the *right* choice (at least from their
    perspective), quite commonly it is the *only* choice.
    
    ps: the particular reason UCX was thrown out was because it did not
    implement file sharing and locking. I understand that this is not in
    the NFS spec, but pratically everyone else does it, and that is what
    the customer needed. I also know UCX engineering have their budgets and
    heads slashed, but that does not detract from the fact that with UCX we
    don't have a working solution.

    Re: .110
    
    Then it's a shame that, as far as I know, no one in the UCX
    engineering group ever heard of your plight.  NFSlockd is a high
    priority item for the next development cycle.
    
    tim
    

    re: .107 and .100
    
    My point was that there is an alternative to both UCX and TGV, and it
    is also owned by DEC; A lot of the UCX futures are already in ANET+.
    
    It's just that for some (DEC internal) reason DEC Japan has been
    prohibited from making the software available for sale world-wide.
    
    Dave

    Deep rathole alert ...


    Much as I'd love to avoid this discussion, it's hard to resist countering
    the FUD that Dave Garrod has tossed in the direction of Phase V alias...

    Lest you have gotten the wrong impression, Phase V *does* support
    cluster alias, and does *not* require a router in the cluster the way
    Phase IV does. It *does* require one router per LAN which speaks Phase V
    protocols. Dave's correct that this usually requires the addition of
    said router, because resources never permitted the completion of
    host-based routing for Phase V. The alternative would be no Phase V
    alias at all.

    There are a number of positive advantages in the Phase V alias design.
    Phase IV alias only supports up to 200 alias connections per node.
    Phase V alias allows for 65K alias connections across the cluster (so
    in a 64 node cluster you could have 1K alias connections per node). The
    maximum number of alias members is no longer 64 - it's more like 1024.
    There is no longer a performance deficit when communicating with a
    Phase V alias as compared to an individual node in the cluster. Control
    over the selection weighting (which nodes get how many connections) is
    much cleaner in Phase V. None of these improvements are dependent on
    the OSI side of the house.

    There is no way to implement Phase V alias such that (1) the Phase V
    alias can be reached by Phase IV nodes, AND (2) a Phase V router is not
    required. NONE. Dave can complain all he likes, but it can't be done.
    Phase IV systems expect to reach an alias using a unique address, which
    requires routing support. I'd be happy to go into more details in the
    appropriate conference (e.g. HELP::DECNET-OSI_FOR_VMS). The router is
    not needed in an all-endnode Phase V network, but it is required for
    the Phase V alias to work with Phase IV systems, or in a multi-LAN
    environment. To make things work the way Dave would like, we'd have to
    go back in time and change Bernie Lacroute's mind back in about 1980
    about how Phase IV LAN addressing works.

    Cluster alias requires support from the routing layer. The nature of
    the Phase IV routing architecture required this support to be in the
    cluster, which is why Phase IV requires routers to support alias. (The
    alternative is to put knowledge at the source, which is what Dave seems
    to suggest, which would really require each end node in the network to
    either know or somehow learn which nodes are aliases and which nodes
    make up those aliases across the entire network. This approach was
    rejected for a lot of good reasons, including poor performance and lack
    of transparency.)

    In Phase V, one router on a LAN can support all aliases on the LAN
    (multiple routers can be configured for redundancy). The only catch is
    that this router needs to understand Phase V endnode hello messages,
    which is the reason that existing Phase IV routers can't fill the role.
    (Phase IV routers can't separate the LAN address from the routing
    address of a node.) 

    RE .-1
    
    Yes I understand the technical reasons behind why it wasn't done. But
    as pointed out by others customers don't care about that. All they care
    about is that upgrading the DECnet version breaks cluster alias
    support. The answer is to find some way of getting a WANROUTER 90 per
    LAN to these customers without them perceiving it to be a cost to them.
    My suggestion would be something like the following. Produce a special
    version of WANROUTER 90 code that ONLY does cluster alias support. Loan
    a customer a WANROUTER 90 with this code ie code that cannot use the
    sync port. The customer now has cluster alias support at no cost. In
    all likelyhood the customer will eventually buy the WANROUTER 90
    to get use of the sync port.
    
    My point is that each and every barrier to upgrading the DECnet version
    has to be fixed. I believe this cluster alias problem is the only
    significant problem.
    
    Dave

    Hmmm... I'm typically a read-only member of this conference. However,
    I've been supporting UCX for over three years. I am the CSC/CS Open
    Systems Support team focal for this product. I have seen UCX functionality 
    GROW tremendously over the past three years. I have also seen the QUALITY 
    IMPROVE tremendously during this period.
    
    Two years ago if someone told me I'd make that last statement, I'd have
    offered make a SUBSTANTIAL bet. At one point I had a memo drafted and
    ready to send to DELTA suggesting that we dump UCX and purchase
    Multinet. Today, I'm VERY GLAD I did not send the memo!!
    
    UCX is RAPIDLY improving in terms of features. UCX Engineering has
    assured us support folks that they are committed to developing the
    BEST TCP/IP product for VMS on the market and I have seen enough
    improvement to believe them!! There was a time when it did NOT appear
    that DIGITAL was committed to UCX. I believe UCX Engineering was
    very shorthanded during that period. Now that the powers that be have
    realized that open systems ARE the future, I believe this is changing
    and the UCX Engineering group is getting the resources they need to
    achieve their goal.
    
    Now! Where did you get your information that TGV is better? TGV's
    product was compared with UCX V2.0B in LAN TIMES (sometime around
    the April/May timeframe) -- Joel Snyder rated the products EQUAL
    in terms of QUALITY and SUPPORT. The UCX shortfall, features.
    However, V3.0 addresses some of the issues around key missing
    features. Releases beyond V3.0 will continue to address this,
    assuming Digital continues to provide UCX Engineering with 
    the support they need.
    
    Rigorous testing by DN&R labs also rated the products equal in
    terms of performance.
    
    [Last two paragraphs summarized from a mail message received from
    the UCX product manager in April 1993 -- fyi]
    
    As a support person, I can tell you that quality improved GREATLY
    between V2.0B and V2.0D. If we were EQUAL in V2.0B, there's a good
    chance we're BETTER in V2.0D!
    
    I talk with lots of customers who another vendors products -- FUSION,
    Wollongong, Multinet, etc. and UCX. Yes, sometimes the other vendor's
    product has a feature UCX doesn't have or doesn't 'break' in the
    same way. But UCX IS IMPROVING. 
    
    I used to support FUSION when Digital marketed/supported it. In fact,
    for a VERY BRIEF period I was the CSC/CS focal for this product too.
    This was a CLASSIC example of a product which looked MUCH better than
    UCX on paper in terms of functionality, but... if the features don't
    work and obtaining support is difficult, what good are all these nifty
    features? The answer -- Digital NO LONGER markets and supports FUSION!
    
    I have no personal experience with Wollongong. I have spoken to several
    customers running Multinet who called Digital for support rather than
    TGV (even though they purchased the product and support from TGV). What
    can this mean -- I don't know. I guess they were more comfortable
    dialing our 800 # maybe. I put my hands on Multinet once... I was able 
    to confirm a rumor I'd heard -- that the command interface performance 
    was slower than UCX -- this may have changed, I'm just using this as
    an example of something UCX was rumored to do 'better' than TGV which
    I confirmed.
    
    UCX (DEC [oops!] TCIP/IP Services for OpenVMS (and AXP!)) is DIGITAL's
    TCP/IP product for VMS. As long as the company is providing resouces
    to develop and support this product, the sales folks should be selling
    it whenever possible! If a sales person is in doubt, they should contact 
    the product manager (Jeff Lukowsky, DELNI::LUKOWSKI) and get the necessary
    resouces involved to determine if UCX can be sold as the best choice
    either now or in the near future.
    
    If a critical technical issue arises. Contact the CSC/CS or UCX
    Engineering. Randy Boyd, NAC::BOYD, is the support focal in UCX
    Engineering. I find him to be VERY responsive. There are a number
    of UCX Engineers (like Tim!) who will be happy to get involved in
    critical issues. (Sorry, I'm not meaning to speak for UCX Engineering,
    but my experience has been that they have become very responsive!)
    
    Well, so much for read-only...
    
    Jim Morton
    Open Systems Support
    CSC/CS

    I agree about the customer perception issue, and I think it's a good
    idea to make the WANrouters easily available. Final nit - the WANrouter
    has no special cluster alias code it in (that's all in the end nodes in
    the cluster). As you point out, a WANrouter with only a single
    connection to a single Ethernet could function as an alias-only router.

    However, I think it would be a bad message to offer a "crippleware"
    router like that. I think it's more reasonable to throw in a free
    WANrouter 90 with the first full-function license per LAN (and try to
    figure out how to avoid giving away more than one per LAN). I just think
    it would be easier to administer, and less overhead, then the work
    required to first cripple, and then support, the "gratuitous WANrouter". 

    On the other hand, I don't have the financials...

RE: .104

>       I'm sorry I didn't QAR every problem and issue I had, but I haven't
>    had enough time lately to do such things; I need software which lets me
>    get my job done as cost-effectively as possible.  Installing DECnet/OSI
>    Wave 3 was a disaster.
 
I'm sorry to hear that.  Believe me, I know there are still problems out there
and we want to hear about them and fix them.  Fortunately, your experience is
not typical, but that does not mean it is not real.  Tell you what - if you'll
try it again :-) I'll be available in an instant to help figure what the heck is
going on.... just give me a call or send mail.

Thanks.

    Ok, Ok,,
    
    UCX is good...
     
    Phase V is DECnet +
    
    
    So when do you do the massive advertizing campaign for these 
    products.  TCP/IP is only a netowork link.  OSI isn't required 
    by most folks today.  How do you make it important to customers,
    you know-- get them excited enough to see it as an added value?
    
    
    When do you do some real marketing to convince the rest of the 
    world that DECnet/OSI is only 5 questions away and that UCX is 
    much better than last year (and of course we all know they 
    froze the code on TGV's product right?)
    
    UCX... I'm tired of all the promises, I'm tired of all the pain...
    And I'm a DEC employee... Think how our customers feel...
    
    OSI -- I don't want to stop OSI but keep Phase IV support around
    and fix the WAN drivers for PSI... Installing the latest WAVE
    of OSI software isn't something my customers want to do.  Get 
    OSI out and establish a track record.  I've got folks on VMS 5.5-2
    because they are waiting for OpenVMS V6.1 to come out before even 
    considering upgrading -- NO MAJOR VERSIONS UNTIL DEBUGGED seems 
    to be the battle cry...
    
    Cheap Shots:  Come on down to my customers, and at DECUS, then
    you'll hear some really cheap shots...
    
    John W.

re:    <<< Note 2846.118 by DPDMAI::WISNIEWSKI "ADEPT of the Virtual Space." >>>
         -< Cheap Shots?  All customers do is give me CHEAP SHOTS... >-

Gee, John, I attended the DECnet/OSI Update Session at Network Academy 
expecting you to state your case, but it was all pretty unemotional. I commend 
Judy Cross for making it very clear as to what DECnet/OSI is and how it isn't 
the end of the world for our customers.

The $4.5M needed to move the Easynet to DECNet Phase V is another story. ;-)

Regards,

Jim

Several of us have been attacked for our responses in this string (cheap shots 
etc).  Please keep in mind that all we are doing is reporting on what our
customers are telling us!  We are asking tough questions in here, in order
to get the answers which will satisfy our customers tough(er) questions.  We
are skeptical in here in order to gather ammunition to convince our customers
to spend their hard-earned cash with us.  And when we report that there is
a perception problem with one of our products, it is because our customers
are roasting us over the problems they see.

Please keep in mind that we are all on the same side.


RE: .101  -< It's DECnet Vn+1 >-

>    I think your note is disingenuous. You basically put up a straw horse
> [some text deleted]
>    All very logical but the basis of your argument is WRONG.

I find it interesting that after many notes in this string telling us how
wonderful and revolutionary DECnet/OSI is over DECnet Phase IV, the emphasis
has shifted to "it's no big deal".

Ok, assume for a moment that your statement is accurate, that it is no big
deal to upgrade from Phase IV to Phase V, and that 99+% of the people who
are involved in the upgrade don't even notice.

How do you reconcile this with the 4 months it took to convert one of our
production systems from Phase IV to Phase V, and the estimate of $4.5M to
convert the Easynet to Phase V?  Was it poor training on the part of the
people doing the conversion?  Were they working on older versions of Phase V
that had bugs which are now fixed?  Please help me with this...

And before you think I am being a smart-mouth who is just interested in
taking cheap shots, keep in mind that the competition is planting questions
just like this one in our customers minds.  If I don't have the answers
to these questions, then *DIGITAL* loses.  Me, you, everybody.  So please
help me with the answers, and don't just shoot the messenger...


RE: .103

>    Digital already has what appears to me to be a high quality full
>    functionality TCP/IP product, known as ANET+. Unfortunately it
>    was 'not invented here'; ie for some reason the DEC Japan folk
>    are not allowed to make it available world-wide. (BTW, they 
>    already have it running on VAX/VMS V6 and on AXP/VMS, too)

How typical, and how frustrating...


RE: .106

>>Ok, tell me the channel by which I can report the lack of X.25, P.S.I. and WAN
>>drivers in OpenVMS V6.0 under Phase IV, and get it fixed in a matter of days...
>
>	It would have been usual to issue at least new versions of
>	this software for a major operating system upgrade. So rather
>	than having to re-install new point releases of PSI and
>	WANDD, why not just install DECnet/OSI V5.7? ( Which is
>	available in a matter of a few weeks ...).

I think your last sentence gives you the answer.  Why didn't I install the
X.25/P.S.I./WAN drivers?  *BECAUSE THEY WEREN'T (and still aren't) AVAILABLE!*
Oh, yeah, they will be shipping RSN (real soon now).  That hasn't helped my 
customers for the last 6 months...


RE: .107
    
>    I don't think you're aware of the whole picture, here.  Are you aware that 
>    TGV is the number TWO TCP/IP vendor on VMS?  UCX has a larger market 
>    share...the largest.
> [some text deleted]
>    point.  Are you aware that UCX revenue's are astronomical, and the revenue
>    per-engineer is in the millions?  Yes, plural, millionS.

I finally figured out how both the field (who reports that no one is using
UCX) and UCX people (who report phenomenal sales of UCX) can be correct.

My customer just ordered 145 AXP and VAX workstations running OpenVMS.  With
those they ordered NAS-250, which includes UCX licenses.  They also ordered
145 TGV licenses.  Guess which one they are planning to use.

So from my (and my customers) point of view, UCX is not in use at this site,
and TGV is the preferred IP vendor.  But from UCX peoples point of view,
this customer just bought 145 UCX licenses, and so must be thrilled with UCX.
    
>    Furthermore, has it occurred to you that it might make the most sense
>    to finally endorse our own TCP/IP product, and provide real corporate

I would love to.  My customers won't.
    
>    The expense and effort required to fix the few problems in UCX is far
>    less than what you suggest - I would suggest that you understand more
>    of the story before suggesting that we shoot ourselves in the (revenue)
>    foot yet again.
    
Sorry Tim, but right now I am gaining revenue for Digital in the only way
that my customers will allow:  by combining Digital and third-party products
into a business solution for their problems.  If I proposed an all-Digital
solution, I would get no revenue at all.

And if the "expense and effort" is so minimal, then where is NFS client?


RE: .108
    
>    It's no wonder, since their local DEC 'technical support' is pushing
>    our competition's product.  Incidentally, I came from the Florida
>    District, I know your customers, I was your predecessor down there.  If
>    they're voting against UCX, then you're encouraging them to take
>    revenues out of our own pocket.
    
No, I am not "pushing" a competitor's product.  I am recognizing that these
people *WILL NOT* use UCX (even though our software packaging mechanisms
make it seem like they love it).  I am recognizing that it is better to be
a "solutions provider" who crafts the best solution to the customers business
problem, rather than someone who tries to sell that they won't buy.

My choice is clear:  I can spend time overcoming the *horrible* reputation
that UCX has with my customer (and they are quick to remind me of the 
numbers of crashes that they have had), or I can accept their political bias 
and spend time selling them other Digital products (new AXP workstations,
printers, networking gear, services, etc).  Now that I report to Sales,
they want to see *REVENUE*.  They do not want me to spend weeks setting up
demos, installing loaner hardware and software, running large tests, etc.,
in order to demonstrate that one of our products no longer has a problem.

>    ...you are, if anything, decreasing revenue...and incidentally, do you

No, I am not decreasing revenue at all.  UCX still gets to report large 
numbers of sales, because they are bundled with NAS-250.  And Digital still
makes a profit on every TGV license we re-sell them.  So I am *increasing*
revenue, at our customers expense since they are buying 2 IP licenses but
using only 1.
    
>    [NFS locking] is a high priority item for the next development cycle.
    
Don't you see this as a problem?  Many features that our competitors have 
had for years (NFS client is the biggest), we have as "a high priority item
for the next development cycle".  This doesn't help my customer today, and
in today's world, if Digital won't supply it, customers will not hesitate
to look around for it.


RE: .116

> [many points concerning the improvement in UCX quality]
>    Now! Where did you get your information that TGV is better? TGV's

From my customers who did their own evaluation of both.  During the eval,
I was a strong supporter of UCX, on the phone to support, working with
network partners, getting patches, and in general doing everything I could
to make sure the Digital product beat the competition.

We lost.

I cannot propose that we re-open the competition.  When my customers pick
a standard, they stick to it.  
    
-- Ken Moreau

The primary reasons for the 4.5M for the Easynet is so that it goes
multi-protocol (ie. DECnet, OSI, TCP/IP ..).  That basicly means
replacing all the routers on the Easynet (which the DEMSAs only do
DECnet).

How many production systems are running VMS V6.0?  How long until
they upgrade?  DECnet/OSI upgrades are no different than planning
a major upgrade to a new VMS version.

    As has been pointed out before:
    
    Upgrading the DECnet version on end systems
    
    and
    
    Upgrading the Network infrastructure
    
    are two totally independent things. The large numbers you have seen
    bandied about regarding the EASYNET refer to the latter thing.
    Please let's not confuse them.
    
    Dave

    First of all, if anyone in this corporation still thinks that we can
    'manage the marketplace' and convince customers that DECnet/OSI (or OSI
    in general) is the one, true, light, then some of us haven't been in
    close touch with reality lately.  It's time we learned to LISTEN to the
    market, not try to control or manipulate it.  Perhaps if we had a
    history of superior marketing ability like, say, IBM, we might have a
    chance at managing the marketplace, but let's face it - we don't have a
    prayer.  Give up.  Listen.
    
    Re:.118
    
    >Cheap Shots:  Come on down to my customers, and at DECUS, then
    >you'll hear some really cheap shots...
    
    I did.  I went to each of the past two U.S. DECUS symposia.  In fact,
    in Atlanta our budget was cut so tightly that I was the ONLY one from
    UCX engineering who could go, which is typical of the kind of attention
    the corporation profers on TCP/IP.  I also just completed the briefing
    for the DEES (European support) to fill them in on the product, and
    gather feedback from Europe.  On the way to DECUS, San Francisco, I
    spent a half a week at the Colorado CSC, again briefing and debriefing
    the support people there.  I'd say that, for an engineer, I'm in
    reasonably good touch with the field...
    
    Re:.120
    
    You only confirm my point that UCX as a product has suffered for years
    from underfunding and understaffing - hence the shortfall in
    functionality.  There is no denying that when a customer needs
    functionality that we don't offer, we have no choice but to offer an
    alternative.  That does not, however, justify irresponsible and
    uninformed rhetoric about cancelling one of our most profitable
    software products without first considering the posibility that a more
    economical and intelligent alternative would be to give the product
    full parity that it deserves with respect to DECnet...particularly when
    we have a history of trying to squelch TCP/IP as a whole, and to stick
    our heads in the sand when it comes to true market trends.  I take
    issue with the haphazard, offhand manner in which you dismiss a product
    of which you obviously have only a cursory knowledge in favor of
    handing over tens of millions in annual revenue to a competitor whom
    we finally appear to be actually overcoming.  Having been in your
    actual job in Florida, I can understand your being a little out of
    touch - I know it can be a struggle to keep informed, but you should be
    more circumspect about dismissing a major, growing and increasingly
    stable product such as UCX.  Did you even talk to the product manager
    when you were losing this competition?
    
    Incidentally, NFS Client is currently in field test on both VAX and
    Alpha.  It probably would have been out six months ago - but guess
    what?  We lost a senior engineer on that project...and not a TFSO.
    
    In all fairness, we finally appear to be getting some incremental
    staffing, but the process has been painfully slow.  All the while, it
    has been an uphill struggle to maintain a viable product, overcome the
    quality problems from a couple years ago, and remain competitive with
    TGV, whose only reason for existing is to compete with us...and who
    therefore have no problem with staffing, DECUS attendence (they had
    EIGHT people in San Francisco and 32 sessions...we had 2 people and
    four sessions), and lots of little marketing goodies for customers to
    take home with them: t-shirts, stickers, marketing literature...etc. 
    We couldn't even fund a decent marketing brochure...
    
    When the market is outrunning us, we shouldn't try to 'lead' it, when
    it's all we can do to follow.  And we don't talk about cancelling one
    of the very few products that we offer which is in step with the
    market, and hand over millions in revenue to the competition.  That's
    just plain dumb.
    
    tim

    Tim:

    Our customers don't care about our staffing problems.  They do care
    that we've been promising NFS client on OpenVMS for over two years, and
    we have yet to deliver.  Yes, some of them will be happy when we
    finally deliver NFS client capabilities, but for many, it's way too
    late -- we lost 'em, and we'll never get them back.

    I've been managing a project recently that uses TCP/IP; we've used
    both TGV's Multinet, and Digital's UCX -- if you'd like to hear the
    details of my group's experience, I'll put you in touch with the
    software engineers, but I suspect I know which product they'd
    recommend.   (Hint: we don't make it.)

    .82 is now unhidden.
    
    		Steve

 
    This file is full of frustration.  The frustration comes from having
    been  the leader in a growing network market, and  then not following
    that market as it changes.  In the late 70's and early  80's, when
    DECnet was becoming mature and the Easynet was doubling in size  every
    six months - DECnet was really the only alternative to SNA for large
    production quality networks.  TCP/IP just became mature enough for 
    commercial use in the late 80's, but today, it's there.  Digital's
    growth  in the 80's was a large part due to providing leading edge
    customers with a  distributed computing environment.  I believe a major
    part of the decline  is the failure to embrace TCP/IP fast enough and
    accept that OSI was at  best a future market.

    DECnet is critical to those leading edge customers of the 80's who
    built  an infrastructure and applications on Digital's solution.  The
    fact that  you are reading this means you're still using VAXnotes, a
    DECnet dependent  application.  DECnet is now DECnet/OSI for many that
    want to take advantage  of new features that make use of DECnet/OSI. 
    For those who are sticking with DECnet, moving to DECnet/OSI much like
    the conversion from vinyl  records to CDs.  There is no stopping it. 
    Some niches of OSI demand will add new customers, but mostly,
    DECnet/OSI allows the thousands of DECnet  customers to choose if and
    when they move from their 1980's based distributed  applications
    (VAXmail, VAXnotes, VTX, RMS, CTERM, NCP, PHONE, FLIGHT, etc).

    The point people are screaming about is that the TCP/IP market is
    growing  at an amazing rate, and Digital is not reaping the rewards of
    being in the  networking business for over 15 years.  If OSI really has
    over a billion  dollars of RFPs out now, as claimed, there must be over
    10 billion dollars of  TCP/IP business to be had.  What is Digital
    doing to get it!?

    The answer actually is LOTS.  Most if not all of Digital's networking 
    equipment can now support an IP address and be managed with the SNMP 
    protocol used in TCP/IP networks.  The TCP/IP stack on OSF/1 is a
    screamer, the SEAL security gateway for IP is good enough for the White
    House, and  the broadcast IP solution is good enough to be certified by
    the SEC for  financial transactions.  

    New announcements will allow laptops to roam while keeping their IP
    address,  and PATHWORKS runs over IP, which has reduced a lot of
    customer's DECnet  addressing problems.  Digital's IP network (DIPnet?)
    is over 15,000 hosts and the new POLYCENTER NetView product will manage
    IP hosts three months  before it gets DECnet (4&5) support.  It ain't
    all bad news!

    What is missing is the top down strategy stating that Digital will
    become a smart choice to get products and services to build TCP/IP
    networks.  Our  strategy must NOT be a bait and switch.  DECnet/OSI is
    for customers that need  to maintain what they have, new customers that
    need what's already been built  to use DECnet/OSI, and the OSI niches. 
    In the IP world, users can today  run OSI applications over TCP/IP
    using (I believe) RFC-1006.  WHY CANNOT THIS BE DONE FOR DECnet APIs!?  

    Converting the Easynet to DECnet/OSI is not going to help Digital
    network users understand the applications being used in customer sites,
    or the  problems that customers are willing to pay money for to have
    fixed.

    Digital has programs to convert OpenVMS users to UNIX - why not
    programs to  help customers convert DECnet to TCP/IP.  The money that
    DECnet is bringing  in doesn't have to go away - but the money being
    missed by not embracing  TCP/IP in an era that is demanding it could
    help the stock price.

    bill

>WHY CANNOT THIS BE DONE FOR DECnet APIs!? 

It can.

And it could be fixed in the next (after 5.7) release for DECnet/OSI on VMS.
(If you want to discuss details, best to go to the DECnet/OSI notesfile,
 .lkg.help::decnet-osi_for_vms)

    re .-2...
    
    > fact that  you are reading this means you're still using VAXnotes, a
    > DECnet dependent  application.  DECnet is now DECnet/OSI for many
    
    I happen to be reading this file using DEC Notes (V2.5), which works
    just fine with TCP/IP (UCX) as well as with DECnet.
        

    >>if you'd like to hear the
    >>details of my group's experience, I'll put you in touch with the
    >>software engineers, but I suspect I know which product they'd
    >>recommend.   (Hint: we don't make it.)
    >
    >If this is an important project, and your own company's product doesn't
    >meet the need, I would have thought that you would have already
    >contacted the product manager or engineering by now to point this out. 
    >Have you?  Yes, of course I'm interested - but it shouldn't take this
    >forum to bring it up.
    
    Of course we contacted engineering.  We told them exactly what we
    wanted to do.  Their response?  "You can't do that."  Funny, we could
    do it with vanilla TCP/IP on OSF/1, and with TGV.  
    
    Eventually, we got our software working with UCX, but we had to write
    UCX-specific code -- something we didn't have to do for TGV or
    UNIX-based TCP/IP.
    
    Yes, they do have nice tie-dyes.  Their software works, too.
    
    					andrew

    There's a big difference between "We can't do that", i.e. missing
    functionality, and "They're software works", i.e. quality.  UCX works. 
    It has not had the funding or staffing that TGV enjoys to build a full
    function application suite, but it DOES work just as well as Multinet.
    
    tim
    

    Listen folks,
    
    The days of having a "Built-IN" DECmarket just because you're DEC
    engineering are waning...
    
    I'm asked more and more to be a system integrator, an recommend
    what can be supported, what works out of the box, and what 
    we can expect the least amount of trouble with in an implementation.
    
    You have to sell my customers because as a Digital Employee I will 
    look at our products first, but if they are wildly out of phase
    (for what ever reason) with the market I will have no choice 
    but to sell and use what's expediant and customer acceptable.
    
    I keep all the third party files just like I was doing for a 
    Digital/DG/IBM OEM in the mid-80s before I joined Digital, 
    most of my field counterparts are doing the same.
    
    You don't like (Pick a DEC product)... Fine lets use something
    else...
    
    What's the best product for AS400, Brouters, SNMP management at
    a specific price?  
    
    I have to be ready to help , add value, and reduce the sales 
    cycle time as much as I can.
    
    We've been hollering here about UCX and the DECnet/OSI issues
    but the simple fact remains that Digital Consulting if it's to
    succeed will have to use and be cognisent of the third party
    products markets.  
    
    If our product is undeniably world class there's no argument
    unless it's irrationally priced...
    
    If it's only EQUAL to or LESS EQUAL then our third party providers
    of software then the choice becomes one of what's the best 
    choice for the customer and the specific project we're working on.
    
    Don't complain to the field that we only had two UCX engineers at
    DECUS or Digital review did a hatchet job on our product and now 
    customers are spooked... Do something about it and maybe the field
    could sell your product...
    
    UCX have been very profitable, OSI has been paid for out of the DECnet
    group which has been very profitable, the threads here are looking 
    for you to use some of that profit to do some Marketing and husband 
    our existing customers sweetly not with a stick.
    
    Fix the WAN drivers for Phase IV, make some concessions to our
    customers who've been paying for all this over the years then 
    offer the OSI migration ON THE CUSTOMER'S TIME...
    
    UCX - market at DECUS, lower the price, increase your functionality,
    do something to show that you're committed to making TCP/IP work
    in the VMS space.  I've had four years of belly-aches and promises
    if you can't do it right, get out of the market...
    
    And as to the folks who've touted our support and field support of 
    our products look again.  We've lost the local FS folks who did that
    support and escalation last Monday.  Seems like all support now comes 
    from a 1-800 number that takes hours to get a call back even regarding
    main stream products..
    
    (Anyone Called the Support lines lately? Try calling support after 
    hours... Then call Microsoft Soft to hear how it should really be done.)
    
    I'm sorry folks to put such a negative slant on specific products and 
    services here in this notesfile but some of you make it sound like
    you've never heard about many of these issues before.
    
    If the field isn't able to easily sell an Digital product, it won't 
    be sold, they'll opt for third-party product that we can make a 
    profit on reselling.  Last year we did it with PCs, Network
    bridges/hubs/routers, Software, and other vendor's largescale
    computer systems, and more.
    
    We want to sell our stuff but when it doesn't sell easily, we're going
    to sell something else (at a profit) and move on...
    
    Nothing Personal.. this is buisness...
    
    
    John W.

Note 2846.108 by NAC::TRAMP::GRADY
    
    >It's no wonder, since their local DEC 'technical support' is pushing
    >our competition's product.  Incidentally, I came from the Florida
    
    that's right tim. and they are pushing the competitions product by the
    ten-of-millions $'s. let's back off of "why" customers buy a particular
    product and focus in on "why" DEC employees are pushing the compeitions
    product at such levels. it would be nice to say we in the field
    evaluate the price, the robustness, the quality of products and,
    understanding what the customer really is trying to do, recommend the
    best products. MANY MANY times it never gets that far. it's simple. 
    
           YOU GET WHAT YOU REWARD!!!! 
    
    and DEC is in the process of losing those 10's of millions of revenue
    precisely because DEC provides little or NO incentive for us to
    sell them. that's right. little or NO incentive to sell them. i can
    hear them coming now:
    
      "your an employee of this company"
      " your a stockholder"
      "where's your loyalty to DEC?"
      "etc. etc. etc."
    
    well there are whole organizations in this company that get 100% certs
    credit for selling ...oh say TGV ... and little or none for UCX. think
    i'm joking? i have bitched about this to the highest levels of this
    company because i CARE about this company. all it has gotten me is
    grief. it is painful to watch DEC destroy itself from within because of
    garbage metrics like this. and until that is changed and changed
    BIGTIME there will continue to be literaly hundreds of DEC employees
    who will continue to ask one and only one question before deciding
    whose product to push and that  quesiton is:
    
        "do i get credit for this?"
    
    it's gotten so ridiculous that when i have held the DEC line i've had
    to run internal DEC gauntlets to get OUR people to even present DEC as
    an alternatives. it sickin's me to see this. but i've decided i can't
    save DEC from DEC. and until this is solved LOTS of folks will continue
    to push Cisco, Synoptics, Cabletron, TGV. etc. etc. etc. etc. and
    whether or not DEC has a competitive product won't even be considered.
    
    good luck.
    
    gene (still trying to give DEC a chance inspite of DEC)

RE: .123

Tim, I appreciate your efforts in reaching customers and staying in touch
with the field as you do.  I know (from personal experience) that actually
breaking out of the GMA cocoon and getting actual field data is tough.

But don't shoot the messenger, Tim.  You want field input?  *HERE IT IS!!!*

> 		    That does not, however, justify irresponsible and
>    uninformed rhetoric about cancelling one of our most profitable
>    software products 

At Digital right now the highest levels of this company are deciding what
people/groups/products/etc to keep and which to let go.  I don't think
such discussion is either irresponsible or un-informed.  

And you have not addressed my original point:  most of the sales (and profit)
of UCX are based on the fact that it is bundled with the NAS packages, and
therefore bundled with VAX and AXP hardware.  Please look at how many UCX
licenses have been sold last year *on their own*.  If it is not confidential,
please share that with us.  We will then compare that number to the number
of TGV licenses sold last year *on their own* (since TGV does not enjoy
the marketing advantage of being bundled with NAS-250).  Then we can see
which product customers are buying in an open marketplace.

I suggest that the problems of UCX are three-fold:

1) A lack of competitive functionality (NFS client, byte-range locking).
   The reasons for this lack don't matter, the fact is that the product 
   does not have the functionality *TODAY*.  And don't talk to me about a 
   field test product:  if it isn't in the price book today, if I can't 
   make this week's revenue number with it, then forget it.
        ^^^^^^^^^^^
              ^ this is not an exaggeration but an actual statement of fact

2) A history of poor quality.  Again, the reasons for this history don't
   matter.  Further, the quality of the product today almost doesn't 
   matter, since the current product has been tainted by the history.

3) The competitive products are well known, full function and high quality.

Tim, you seem to feel that the customers are begging the Digital Sales Rep
and Sales Support to sell them UCX, but that the Digital people are going
out of their way to betray Digital and sell a competitor's product.  Nothing
could be further from the truth.


RE: .131

>    There's a big difference between "We can't do that", i.e. missing
>    functionality, and "They're software works", i.e. quality.  

To a customer there is *no* difference.  The only thing that matters to a
customer is that the services they want are available 100% of the time (both
functionality and quality).  If either is missing, your product is not 
even considered for purchase.

>    It has not had the funding or staffing that TGV enjoys to build a full
>    function application suite, but it DOES work just as well as Multinet.

As Andy Kenah and others said, no one cares about the first half of your
sentence.  And to the customer who wants to mount Sun NFS disks on OpenVMS, 
the second half is false.


RE: .133

I don't work for MCS, so I get less credit for selling a competitor's
product than I do for selling a Digital product.  So I do try to do the
evaluation of the respective products that Gene talks about.  And when
the Digital product comes up short, I try to feed this back to Product
Management.  In this case, we gave Jeff Lukowsky plenty of feedback when he
spoke at OpenVMS Partners 14 months ago (13-Oct-92, 3:30 PM).  He listened, 
and then made some very strong statements, including NFS client and PC-NFS 
functionality.  Then in the following OpenVMS Partners meeting 8 months ago 
(22-Jul-93, 10:00 AM), Stacy Humphrey of Networks Business Management said 
we would have NFS client and PC-NFS as well as 2-3 times performance 
enhancements on VAX in November 93 and on AXP in September 93.  

It is now February 94, the functionality is still not in the shipping 
product, and my customers still don't care why it is not there.  They have
problems they need to solve *TODAY*, not "in a future major release".

-- Ken Moreau

	I have a few questions for those in the UCX debate here who have 
compared the product unfavorably in every way:

1.  Where do Multinet (or TCPware, or PathWay) customers get support?  How 
many field support people does TGV have outside of Santa Cruz?  (Hint:  
Count the number of thumbs on your feet.)

2.  Where do customers in the Far East go for sales or service on the 
competitive products?  I've been there; they have zero presence.

3.  What do customers do when they need full UNIX file name semantics on 
their NFS server?  Only UCX has the container file system and can provide 
full semantics.

4.  How many customers are actually *using* NFS clients?  Our conversations 
with TGV, Process Software, and Wollongong indicate that very few actually 
do.

	The number of UCX licenses sold outside the NAS package (i.e., 
licenses where the customer specifically ordered UCX rather than just got 
it in the package) compares favorably with TGV and the others.  Our best 
information is that, in addition, the number of NAS users who actually use 
UCX is of the same order of magnitude as stand-alone customers.

	By all means, if your customer really needs a feature that our 
product doesn't have, sell another product.  But don't get in the habit of 
doing that on every sale.  And bear our advantages in mind.

		David
		NOS Consulting (formerly TCP/IP Program Office, and 
			UCX Engineering before that)

        I have never installed, managed, or used DECnet/OSI on a VMS
        system, but an Ultrix system I use has had it installed (not
        by me).

        I can't believe that anybody who actually had an immediate
        information need ever successfully used NCL's (successor to
        NCP) "help".  I was just trying to find out whether a
        specific network object had been defined, so I was looking
        for the syntax of the "show" command.

        If one types "help", one does not get a list of commands, one
        gets the following:

          Topics available:

          Read_me_first       Tutorial_for_NCL    CSMA-CD_Module      DDCMP_Module
          Device_Module       DNS_Module          DTSS_Module
          Event_Dispatcher_Module                 Directory_Module    FDDI_Module
          Frame_Module        HDLC_Module         LAPB_Module         LLC2_Module
          Loopback_Application_Module             Modem_Connect_Module
          MOP_Module          Node_Module         NSP_Module          OSAK_Module
          OSI_Transport_Module                    Routing_Module
          Session_Control_Module                  X.25_Access_Module
          X.25_Client_Module  X.25_Protocol_Module
          X.25_Relay_Module   X.25_Server_Module

        Can anyone not already familiar with this tell me where the
        "show" command might be documented?  (assuming it is -- I
        never found it).  It does want to give me a tutorial (and
        apparently Read_me_first is the tutorial you need before you
        read the tutorial).  Under Read_me_first you find help on
        Using_NCL_Help, which if selected provides the following gem:

            ... After
            selecting the command, you may select from subtopics such as
            arguments,  characteristics, and so on.  For example, to locate the
            syntax and a list of counters for the device_unit_entity show command,
            enter the following:

              % ncl
              ncl> help
              ncl_help> device_module
              ncl_help> j
              ncl_help> counters


            How to navigate NCL help?

            When selecting help topics, you may abbreviate help topic names,
            provided that the abbreviation uniquely identifies the help topic.

            ERROR MESSAGES: For information on NCL error messages, refer to the
            NCL help topic: Tutorial_for_NCL.

        I'm sorry, perhaps I'm very dense, but I just don't get it,
        and I'm an experienced Phase IV user/manager.

        This NCL help facility is like throwing a treatise on
        buoyancy to a drowning person!

        I believe that to say that end-node upgrade to DECnet/OSI
        entails only five commands is a GROSS over-simplification.

        Bob

    It (NCL HELP) has been completely re-done. Doesn't that make you feel
    better?
    
    A lot of other people (including me) had the same problem as you. From
    my perspective as a user, DECnet/OSI engineering listened to the
    feedback and completely changed the help. You can now type
    	ncl help set or show
    and get useful information.
    
    I'm a bit out of touch with whether this got done to DECnet/OSI ULTRIX
    or not, since we have stopped using this platform, but the
    user-friendlier help has certainly made its way to VMS and OSF/1.
    
    Mike
    (who does not work for DECnet/OSI engineering or receive any bribes for
    expounding positive views towards DECnet/OSI. I just happen to need it
    for my customers.)
    

    As you can see it was improved about 10 months ago. If you want to read
    the rest of the discussion, I suggest you take a look at the other
    replies to note 563 in HELP::DECNET-OSI_FOR_VMS. You will also see that
    engineering actively requested suggestions for improvement and set up a
    team to implement the results - successfully I believe.
    
    Mike
    
          <<< HELP::USER0:[NOTES$LIBRARY]DECNET-OSI_FOR_VMS.NOTE;1 >>>
                          -< DECnet/OSI for OpenVMS >-
================================================================================
Note 563.11                    Online help for NCL                      11 of 12
UFHIS::MMCCREADY "Mike McCready Digital-PCS"         23 lines   1-APR-1993 07:16
                            -< I like the new help >-
--------------------------------------------------------------------------------
    The NCL help for W3BLV4_G is much better. I really like the list of verbs
    since the reason for me to use help is normally to check the syntax of
    commands.

    Is this going to be implemented on other platforms too e.g. ULTRIX & 
    OSF/1?

    Mike


NCL>help

  Information available:

  add        advertise  block      boot       change     clear      connect
  create     define     delete     disable    disconnect dump       echo
  enable     event_messages        getnif     getsif     ignore
  Introduction_to_NCL   limit      load       loop       module_descriptions
  pass       ping       query      read       Read_me_first         remove
  rename     reset      restrict   set        show       shut       shutdown
  snapshot   start      startloop  stop       stoploop   synchronize
  test       testevent  undefine   unlimit    update