Conference 7.286::digital

Here in the CSC we received several notices about this.  Since it effects 
the IPMT gate to engineering I guess someone is taking it seriously.

Jilly

We didn't get not a one...just discovered it when none of or DUNIX boxes could talk to DECdns.

We're hosed.

-Stephen

    This problem is extremely serious and much wider than the USA.  I am
    surprised that the only communication I've seen is anecdotal notes
    like this.  There are a number of suspiciously coincidental problem
    symptoms ;
    
    		- DECnet phase V freezes or extremely bad performance
    		- erratic IP performance (particularly ftp)
    		- localized implementation of protocol prioritisation
    		  (e.g. telnet prioritised above other protocols)
    		- erratic IP DNS performance
    		- saturated arterial links (e.g. VBO to rest of
    		  the world, Easynet to palo alto)
    
    	and of course ;
    
    		- the recent migration of backbone routers to later IS-IS 
    		  protocols.
    
    What is the official position?
    
    Yesterday I logged a formal outage with the Valbonne Network Control
    Centre and today I will follow up with an escalation on behalf of the 
    MCS Division as our work is being impacted.  Has anyone in the USA
    formalised this problem?
    		 
    
    /Chris.

    After two weeks of inexorable decline, we're more or less dead in the
    water here in Brussels, and have been for a couple of days. I do know
    it has been escalated up the management chain to Geneva at least, and
    now has some high visibility. Whether any connections will be made with
    the data in .3, I don't know.
    
    Laurie.

    Hi,
    
    This is what I got in the mail this morning in Holland.
    The message is "Disable DNS if you run any Microsoft TCP/IP stack".
    Not much fun if you run no DECnet.
    
    Regards,
    
    Jan
    
    
    -----------------------------------------------------------------------
    
                            CCS LOCAL SERVICE DELIVERY UNIT
    
                                   SERVICE BULLETIN
    
        For Information Contact The CCS Nederland Helpdesk At Extension
    
                                   838-3100
    
                           Date issued: 01-Mar-1996
        
    -----------------------------------------------------------------------
    
    		 ***** NETWORK RELATED PC PROBLEMS ***** 
    
    -----------------------------------------------------------------------
    
    We are currently experiencing severe network problems which are caused 
    by a configuration error in the Microsoft TCP/IP stack. 
    
    Since we cannot remotely determine the source of the problem, we would 
    like anyone involved with the installation or configuration of the 
    above mentioned stack, to check whether DNS is enabled for Windows Name 
    Resolution. 
    
    If so, please disable this option. If you have any problem or queries, 
    you can contact the Helpdesk for assistance. Please inform the Helpdesk 
    if the Microsoft TCP/IP stack is used in a Windows NT, Windows for 
    Workgroups or Windows 95 environment. 
    
    Your cooperation is much appreciated.
    
    -----------------------------------------------------------------------
    
    Connectivity and Computing Services
    

    Name overload.
    
    MS DNS = TCP/IP-world DNS.
    Easynet DNS = DECnet/OSI-world DNS (see below). 
    
    
    I don't think they have much in common (except maybe they're both
    broken ?).
    
                <<< JETSAM::ENT:[NOTES$LIBRARY]EASYNET.NOTE;2 >>>
                     -< EASYNET Network Notes Conference >-
================================================================================
Note 871.3     Where I find out about corporate wide DNS outages?         3 of 3
STEVMS::PETTENGILL "mulp"                            49 lines  29-FEB-1996 17:11
     -< Well, there is a problem and some way of notifying people, but w >-
--------------------------------------------------------------------------------
         <<< abbyrd::USER0:[NOTES$LIBRARY]DECNET-OSI_FOR_VMS.NOTE;1 >>>
                          -< DECnet/OSI for OpenVMS >-
================================================================================
Note 3236.5                  Keep LOCAL: up to date?                      5 of 5
USPS::FPRUSS "Frank Pruss, 202-232-7347"             35 lines  28-FEB-1996 23:31
                       -< How timely...:How timely :-( >-
--------------------------------------------------------------------------------
        Subj: (U) DNS Network Situation                                       
    
        Date: 28-Feb-1996 02:51 Pm MST
    
        Problem Statement: DNS Network Situation                                
 
    
        Status:                                                                 
 
                                                                                
 
                                                                                
 
                                                                                
 
                                                                                
 
    
             CC: ! (GPS_Mail Captive Account)
        Contact: CCS Help Desk            
          Phone: (800)332-2468
            DTN:      000-0000
    
    
    
    DNS NETWORK SITUATION
    
    The corporate DNS (name server) systems have encountered a severe
    problem 
    which has caused all 6 central servers to be only partially
    operational.  Any 
    software which depends on DNS for message routing is affected.  Many 
    production systems including several mail systems are impacted 
    (not communicating across the network).
    
    Corporate Telecom, Digital Engineering, the NOC and MCS are currently 
    working on the problem.  At present, there is not an estimated time of 
    resolution.
    
    
    

    

    The following extract is the formal communication from the European
    Network Operations Centre.  I think it falls far short of explaining the
    terrible IP problems we are experiencing but it confirms the DECdns
    issues.
    
    No timescales are promised for a fix.   I'm hoping for Monday morning
    at which point I'll be reviewing the impact of any remaining IP
    issues on the MCSD business.
    
    Any of you with serious unresolved IP issues - I strongly urge you 
    to send a statement of business impact to your functional CIO.  
    
    /Chris.
    
Subject: DECdns outage notification




        

	PLEASE DISTRIBUTE THIS AS WIDELY AS POSSIBLE TO END USERS COMMUNITY.



	A major problem is affecting the DECdns roots servers worldwide.

        The perceived impact at end user level is:

        Networking only over DECNET is affected , IP is OK .
						          
 

        You may have problems with  :

             - Set host command

             - mail delivery (ALLIN1 VAXMAIL...)
         
             - Copy and File transfers 

             - Client Server applications using DECnet



        We are doing our utmost to fix the problems.

        Regards,  
        DNS team.

        

IS to IS routing?

Is there a notes file or web page on it?

-Stephen

Last few days I have ftp'd loads of data, both 
over external IP connection and over internal IP (between
vbo and US). 
I have not noticed any problems (from 2 different subnets here)

I have noticed that reply'ing to (or sending to) mail-agents which
transfer over DECnet (MessageRouter) have problems. But this problem
is due to over messaging backbone, which is maintained in some locations,
some seems not to be well maintained (if at all).
I have seen this growing problem over about 2 years - and I can not
tell if the non-deliveries I get, is because of this, or for
DECnet DNS problems. 

/britt
[Posted by WWW Notes gateway]

Presumably this is not affecting DECnet Phase IV, just Phase V (since
i can set host and do VTX and NOTES from Phase IV systems)?

- paul

Re .10

Not entirely true.  It would affect anything which uses DNS - a list which
includes more than just DECnet/OSI and does not actually need to include
DECnet/OSI.  It could affect PhaseIV+ systems that have DNS lookups enabled, and
it will not affect PhaseV systems which don't use DNS (my DECnet/OSI system for
example relies on local file and bind for name resolution).

fwiw,
--Scott

Right now, and since last night, both proxy servers:

	www-proxy.pa.dec.com (204.123.2.44)
and 
	www-proxy.crl.dec.com (192.58.206.21)

as well as

	decuserve-gw.pa-x.dec.com (204.123.3.7)
	(and the other things in 204.123.3)

are unreachable, at least from three subnets at ZKO (16.32.48 & 16.32.0
& 16.32.80).

When this first started happening, I had a terminal session open to
DECUServe.  Data being sent from DECUServe to me was still arriving
and being displayed for more than five minutes after it was no longer
possible for any data I sent over the terminal session to reach the
other end.

/john

Can anyone tell me if the problem I mentioned in .-1 (both proxy servers
and other gateway services unreachable) is being experienced _now_ by
people in locations other than ZKO?

I called in a trouble report yesterday morning, but the problem persists.
I know that people were working on it, but it was Sunday, after all.

Thanks/john

From ILO (Galway, Ireland) I can ping www-proxy.pa.dec.com and
www-proxy.crl.dec.com with some timeouts but decuserve-gw.pa-x.dec.com
is dead even with a wait time of 3 minutes.

Joe.

    Who is sponsible at the corporate level for seeing that this 
    mess is resolved - it is really starting starting to hurt us and 
    I want to make sure the powers-that-be understand what is going 
    onnd how upset customers a are becoming with us!
    
    Barry  Nestor
    Electronic Connection User Support

    re: -.1 Be assured that this has the visibility that you want at the
    highest levels of the company.  This is having a MAJOR impact on our
    ability to do business of any kind, and a lot of people are really
    "upset" (not just grunts).  One of the problems appears to be that we
    seem to have TFSO'd many of the people who had any understanding of the
    nuts and bolts of DNS, so getting support from Engineering is
    "problematic".  At least that is the rumor du jour around here.
    
    Regards,
    
    Bill

as a minor (or is it a major) nit, I'm getting confused by all this reference to
DNS.  From the context of it all, it sounds like we're talking about DECdns and
not the REAL dns as used by TCP/IP.  I seem to recall in some earlier notes,
some people mentioned dns as the root of all the problems and a bunch of other
people went off looking at TCP/IP.

we may think we invented the acronym DNS, but we didn't and if we keep using it
incorrectly a lot of people are going to get confused...

-mark

Mark:

  I think I've seen you in the other conferences so I suspect you
  already know this but:

  Lots of things seem to be broken simultaneously. There may be
  a few common causes but there also seem to be independent causes,
  or causes that are connected only by "second-order effects".

    o We have router problems. This appears to be due to some
      upgrades that were not noticed to be broken until the
      last routers were upgraded. If I understand things
      correctly, this is the cause of the DECnet Phase V
      problems.

    o We have bandwidth problems. This is due to the bean counters
      inexorable drive to minimize costs without regard to any
      expense to our productivity. This lack of bandwidth is the
      root of the IP packet delays and losses reported. I wonder
      if it isn't also a secondary cause of routing instability?

    o HUMANE::, the node hosting this conference appears to be
      broken as it often replies with "Network partner excited"
      or, with a lesser frequency, other DECnet error messages.
      It's probably broken all-on-its-own, but there's probably
      also the secondary effect of heavy traffic into HUMANE::
      as people try to find out what the heck is going on with
      our networks.


  As several folk have already observed, the one truly common cause
  is our corporate anorexia. We tossed all or most of the people
  who made this ship run, and now we wonder why there's no one left
  to work the pumps when the place starts leaking.

                                   Atlant

    Order status via the Electronic Connection is now functioning...It had 
    been down since last Thursday so SOME progress has been made...I hope!
    
    Barry 
    

    Re: .18
    
    Atlant,
    
        I was about to suggest that we offer up a human sacrifice to the
    great network god, but me thinks you are right....too many human
    sacrifices might be what got us here to begin with.
    
    JMHO
    
    Paul B.

    
    	RE: Paul
    
    	Well, don't toss out the "human sacrifice" idea just yet ... I
    	could come up with a few names if you're interested in pursuing
    	it further.  8^)
    

    re: last few
    
    Do they gotta be virgins?

    
    	If so, we'll have to wait another 7-8 years until they're old
    	enough to be hired.
    

HUMANE was suffering from its own set of problems, probably related to
the Phase V fiasco.  They seem to be cleared up for now.

j.

I hate to be picky here (no, actually I don't) but I believe the network
problems of the last week were DECdns problems, not DECnet/OSI (Phase V)
problems.

Some of HUMANE's problems are DEC Notes bugs.  Some of the things going on on
HUMANE I have never seen in my twelve years of managing OpenVMS systems, and I
only guess they were caused or helped along by the corporate DECdns problems.

Paul

    Does anyone have a handle on this?  I can dial into IVO and establish a
    PPP link.  I can then establish a Telnet or VT session to MKO but
    cannot do the same to IVO???  I can also run Netscape and get
    information off of Digital e.g. wide-area.  This problems seems to be 
    localized in certain areas.  I can't get any work done and I'm leaving
    for Asia on Thursday.
    
    	Regards,
    

    About 4 months ago I noticed problems between the site server (PTOSS1)
    and a workstation (PTOSRT).  I could communicate from PTOSRT (Phase IV)
    to PTOSS1 (Phase V) but not vice-versa.
    
    I did try to log an IM&T call but they said it was something that was
    not likely to get fixed etc.  Bigger issue, no priority etc. and
    something to do with DEC/DNS being corrupt.
    
    Just wondering if this is some type of 'cascade' throughout that data
    base that badly needs to be fixed?
    
    j
    ^--who hopes oneday that his network management demo workstation will
    be able to talk to the net...

Hello,

I am writing from Singapore, and for the past few weeks I have been unable to 
use external sites using Netscape.  The error that I get is:

"Netscape is unable to locate the server www-proxy.crl.dec.com:8080 The server
does not have a DNS entry"  I've also tried this with www-proxy.pa.dec.com:8080 
and I get the same error.

I have no problem when I bypass the firewal, for example:

http:://www.crl.dec.com/Digital/home.html 

But the error reappers when I click on links to the outside world.  I am not 
sure that if this is related to the DNS problems mentioned here since, from
some of them appears the problem is with Decnet and not IP.  In addition the
few Others in my building who use Netscape don't seem to have this problem but 
neither one is running it on Windows 95!

I have also checked the internet-tools notes conference but not much luck there
either.

Any ideas,

Bardia.

    From Brussels, DECNet is working again, but performance for it, and
    TCP/IP, is absolutely dire. This really affects my work.
    
    Laurie.

Can anyone provide a status update as to the steps being 
taken to:

a)  Stabilize/Fix DNS
b)  Improve IP performance

Steve
(who is *Danger Close* to having to sign a contract with
 an ISP to get my job done)

    re .21
    
    Paul and Shawn and others who have suggested it.
    
    Virgins only work with volcanos and earthquakes, a statement i have
    used when customers have suggested sacrificing one on the console of
    any number of vaxen and gateways (not all ours)  I never had anyone try
    a bean counter
    
    The IPMT cases on our gateways and on DNS for the last 6 months might
    make an interesting read for someone, though.
    
    meg

    Well ... I have been forced into the position of having to use my
    America OnLine account through a 9600 baud modem from the PC in my
    office to get any work done on the Web. I also have an ISP but I
    haven't configured this PC to use it yet. That's next ... 
    
    ... I sure hope they get it fixed soon (and before the media gets
    wind of the situation and throws it in our faces).

    As of about an hour ago, TCP has all but died here, and as for Mosaic,
    no chance, that's completely dead. PINGing the gateway shows the
    following:
    
    10 packets transmitted, 6 packets received, 40% packet loss
    round-trip (ms)  min/avg/max = 590/765/990
    
    Laurie.

    Can someone explain to me in simple terms just what isn't working?
    I seem to be able to send and receive email and access internal
    Dec and external sites with Netscape.  Is it that some parts of
    the company have some of these things broken?  Or that the
    pathways from some parts of the company to others or external
    sites are broken?
    
    signed,
    
    puzzled
    

E-mail is fine.  Web access through the proxy server, at least from the east
coast, is not.  Some things go through - eventually, others time out.

				Steve

Even the humble VTX is affected, I find that my access to most of the stuff on 
there is rather iffy at best.  This caused considerable embarrasment for me 
yesterday, for reasons I'd rather not go into...

Chris.

OK, it's time to go ahead and say it.  A big IMHO disclaimer at the top ot this:

DECnet must die...IS to IS routing must die along with it.  *MAYBE* we should keep phase IV on our Vaxen,
but definately DECnet/OSI must go away...

I can't really go into details because it's not really appropriate, but we are being forced
to throw money at this problem...in essence, no longer rely on the easynet for anything.

Now, when a site is forced to completely abandon it's reliance on a core ingedrient such as
the Digital Corporate WAN, something is seriously wrong.

This entire fiasco has dramatically changed my view of this company and it's recovery.  It's
apparent to me that there still is an awfull lot of people holding on to legacy ideals and
legacy solutions in this company.  This is only going to make the changes that *must* come in the
future that much more difficult to effect.

The final step in our recovery is to wake up and smell the coffee...and to reinvent our IS infrastructure.
Our customers have been doing it for years...coming off of NVAX's, eliminating DECnet, and going to
routed IP networks. There is just simply too much concern with *investment protection* in this corporation.
We need to support our customers legacy applications, fine, but where is it written that we have to hold
on to our own for dear life??  DOES Digital know Networks?  Really?  We can't even run our own!!!

And don't tell me it's a question of money!! How many countless hours have we wasted on this problem alone?
You know, it is possible to use metrics to measure cost versus benefit and this one is a no-brainer.

Digital, it's time to become a customer of yourself and solve your IS infrastructure problems...because baby, you
got 'em big time.

I know it's easy to sit out here on the left coast and lob grenades...I really do...but you know what?  If I'm
without power for 7 days...the Power company gets the same treatment...there *IS* no excuse.

-Stephen

OK, it's time to go ahead and say it.  A big IMHO disclaimer at the top ot
this:

DECnet must die...IS to IS routing must die along with it.  *MAYBE* we should
keep phase IV on our Vaxen, but definately DECnet/OSI must go away...

I can't really go into details because it's not really appropriate, but we are
being forced to throw money at this problem...in essence, no longer rely on the
easynet for anything.

Now, when a site is forced to completely abandon it's reliance on a core
ingedrient such as the Digital Corporate WAN, something is seriously wrong.

This entire fiasco has dramatically changed my view of this company and it's
recovery.  It's apparent to me that there still is an awfull lot of people
holding on to legacy ideals and legacy solutions in this company.  This is only
going to make the changes that *must* come in the future that much more
difficult to effect.

The final step in our recovery is to wake up and smell the coffee...and to
reinvent our IS infrastructure. Our customers have been doing it for
years...coming off of NVAX's, eliminating DECnet, and going to routed IP
networks. There is just simply too much concern with *investment protection* in
this corporation. We need to support our customers legacy applications, fine,
but where is it written that we have to hold on to our own for dear life?? 
DOES Digital know Networks?  Really?  We can't even run our own!!!

And don't tell me it's a question of money!! How many countless hours have we
wasted on this problem alone? You know, it is possible to use metrics to
measure cost versus benefit and this one is a no-brainer.

Digital, it's time to become a customer of yourself and solve your IS
infrastructure problems...because baby, you got 'em big time.

I know it's easy to sit out here on the left coast and lob grenades...I really
do...but you know what?  If I'm without power for 7 days...the Power company
gets the same treatment...there *IS* no excuse.

-Stephen

Here at MCS, we have a CIO who stood up and said NO MORE!  We are moving to a
model where the platform of choice will be based on a Microsoft infrastructure,
running things like Exchange.  It's painfull as not everyone is on board, but 
we're getting there.  It's truly amazing how much more powerful current
technology can be.

Just as an example, ya know how everyone who wants to include original text in
a reply always prefaces things with > or ] or whatever?  Using real technology
you just use a different color!  What a novel approach...

-mark

    re .-1
    
    Perhaps the writer of .-1 should ask why Microsoft still uses some
    OTHER platforms for financials etc.?  They may eat their own dog food
    (i.e. office products) but it makes a lousy full meal.
    
    I believe that Microsoft has yet to find a PC replacement for the VMS
    based stuff it uses for business.
    
    So....before we just do the typical "chuck it and toss" Digital
    migration suggested in .-1, perhaps we shoudl fix the problem by
    telling IM&T WHAT we expect, PAYING for the level of service so that
    they can hire and staff to support and stick to our business of
    developing products, selling services, or making money for Digital.
    
    (And, note that MCS investing in cute PC gui tools will NOT fix the
    issues with contracts, SMART, STARS etc.)
    j

re: -1

You couldn't be more off base...

Microsoft is ASGRESSIVELY migrating to SAP on two-tier Windows NT...they have actively 
reduced the amount of business processes off of the VAX cluster...and have moved 
many, many, many, databases off of RDB and onto SQL Server on Intel Servers.  They have killed
DECnet and XNS off of thier network....and gone to IP and SMB over IP.  In fact, I can't think
of a better example for my ealier argument. 

And internationally they use AS400's...they only use VMS for domestic financials.

There is literally no way they can migrate to OpenVMS Alpha.  It's impossible.

They really have no choice but to just dump the whole damn thing.  So there was ABSOLUTELY ZERO
investment protection for these people for running VMS.

The VAXcluster's days at Microsoft are seriously numbered. 

Like I said earlier...it's time to wake up.

-Stephen

    re .-1
    
    Steve,
    
    When you're RUNNING a business you don't just drop things and change
    because something is new and glitzy.  I did NOT say that they were
    putting new applications up, I *DID* say that they are STILL using
    their traditional applications and not just chucking it all and
    changing.
    
    They ALSO have just a teensey-weensey few problems with Email there too
    - trying to get messages reliably delivered, tracking messages, keeping
    all those stables of intel boxes upgraded etc.
    
    New applications, technology, etc., really do make things look nice on
    paper - but in practice, flawed infrastructure support will ALWAYS get
    ya. 
    
    And, remember, it is after all a multi-protocol world.
    j

    Uh, Stephen, you need to make your network a bit *less* wide area
    ... like 80 columns worth.
    
         <<< Note 4454.42 by DECWET::WHITE "Surfin' with the Alien" >>>
                        -< Sorry, that's is not valid. >-

re: -1

You couldn't be more off base...

Microsoft is ASGRESSIVELY migrating to SAP on two-tier Windows NT...they have
actively  reduced the amount of business processes off of the VAX cluster...and
have moved  many, many, many, databases off of RDB and onto SQL Server on Intel
Servers.  They have killed DECnet and XNS off of thier network....and gone to
IP and SMB over IP.  In fact, I can't think of a better example for my ealier
argument. 

And internationally they use AS400's...they only use VMS for domestic
financials.

There is literally no way they can migrate to OpenVMS Alpha.  It's impossible.

They really have no choice but to just dump the whole damn thing.  So there was
ABSOLUTELY ZERO investment protection for these people for running VMS.

The VAXcluster's days at Microsoft are seriously numbered. 

Like I said earlier...it's time to wake up.

-Stephen

    If the same problems were happening at some of our customer sites, it
    wouldn't be for long. I was at one major customer site working on a
    Printserver CLD. This is a customer that we Digital buy milions of
    dollars of their CPUs and supporting chip sets.
    
    So in the course of collecting network data, we Digital MCS and LPS
    Engineering found that the routers in this customers network had a
    problem of corrupting data packets but transmitting these packets as
    good (good CRC). When this was presented to the customer, it was like
    WW III. Memos were sent out to the system managment base. the user
    base. They even went to great lengths to make sure that the Chip design
    data did not become flawed due to this corruption. 
    
    What is funny.... Digital Network Services were being asked to provide
    help in resolving this customers network problem, but we can not even
    keep our network running.
    
    Renis
    
    
    
     

    To the best of my knowledge, no-one who gives a a damn (nor a dollar)
    is reading this thread.  Stop whining in here and call your CIO or
    VP and complain!
    
    The problem is simple.  The Easynet has had fat cut, flesh sliced into
    and now the very skeletal services are crumbling.  I've documented
    the effect on our Customer Electronic Services business and received
    a response stating that tools engineers have been laid off,
    operational people are untrained and overloaded and that bandwidth
    needs a massive upgrade.  I've asked for proof.  The February statistics 
    show the main backbone TDM links running at 90% to 130% during business
    hours.  There ain't no more folks!
    
    When it comes to networks, Digital are becoming the proverbial cobbler's
    children - unshod.
    
    The only action that will produce results is a business level
    escalation to your functional CIO - state very clearly the impact and
    what it is worth to your business.
    
    /Chris.

re: -1

Sorry, but I think I'll continue to exercise my right to
'whine' in this notes file.

This is the one outlet we have for our frustrations...

You really have no idea who is reading or not reading this.
It's accessable to all.

-Stephen

Sure we have great access to the gateways, but we can't get
back east to our source pools...

I did a ping on monday to a machine back east which I need to
access to get my work done and I got 70% packet loss.  Jobs
which use to take a minute to complete are now taking HOURS,
if they complete at all.

How in the hell are we to get any work done when we can't even
access the basic tools we need to do our jobs.

I feel sorry for Stephen as he has about 100 engineers jumping
up and down demanding that this problem gets fixed...  

-Shawn

Someone who doesn't know a DELNI from a DECrouter is probably going to
decree that the whole problem is caused by personal use of mail, notes,
and WWWeb.

/john

Around an hour or so we got a notice here is stow that things were fixed and
sorry for the inconvenience.  I just tried connecting to White Pine Software's
web site and started a download of a 1.5 MB file.  Now I happen to know this is
already a heavily loaded site, but I'm getting around 3KB/sec so perhaps things
have been cleaned up enough for web services to at least begin to function
closer to normal...

-mark

My issue is not with this tactical problem.  It will get fixed
eventually.  In fact, we are taking steps to ensure this kind
of thing never affects us again.  So with that I could just
ride off into the sunset and that's that...just say, 'boy
I'm glad that won't ever affect us again'.

My issue is with the strategic implications of this.  Because of 
this BU structure...which is largely responsible for our recovery...
we seem to have lost the ability to address issues relative to the 
impact to the entire corporation...and as in our case, things just 
get solved by 'what's the impact to the business?'.  Everything is 
tactical...no long term message/vision.  BU against BU.  This is 
just my perception of course...

Those are the kind of things I keep hearing...that and speeches 
about 'it's just technology, it's not the tool, it's the process', 
and 'it's just another Operating System' and 'technology does not 
really matter, it's people'...when all around us, a technological
revolution is taking place, a massive paradigm shift..it's 
amazing to me that in the face of this...people are trying to
maintain the status quo...stare it in that face and offer some
cliche's...

I dunno...this will all be moot to me personally as soon as we 
finish the rewire...I can't help but feel like we are losing our 
corporate identity...and becoming about 8 separate companys...

Heck, we'll be so damn independant here in about 3 months, we 
could just 'spin-off'.

It's disheartening...I enjoy being loyal to the Digital Logo...and 
being on one big Digital Team...now, I guess it's time to pledge
allegiance to my BU.

*sigh*

-Stephen

The weekly briefing from the Americas ABU VP came prefaced with the
following:

                                     NOTE
	Due to Digital's networking difficulties, Reader's Choice
	has been unable to distribute any messages for a 3-day period. 
	We apologize for the inconvenience.
                                    ******
 

So what did they state the problem was?

Inquiring minds want to know.

    We here in a remote European office (Finland) have long had serious
    problems with our Easynet connection. After some research (for which
    we are not supposed to have resources, so people involved do non paid
    excess hours) we have found several factors to this situation. Here are 
    some of the things:
    
    1) Our connection to Easynet, like many others are based on frame
    relay. There doesn't seem to be any continuous testing outside backbone
    of, what is the real bandwith, we are getting compared to our connection 
    speed (hey, there is lot of money involved). One of our CCS(?) support 
    people - who has his responsibility area elsewhere - made a quick hack to 
    check the situation and got ~32k from our 192k link. The situation was 
    worse during daytime, when we need the capacity most.
    
    2) More and more people are using Internet tools and especially WWW.
    This means a dramatic improvement in functionality but at the same
    time in capacity needs as well. We have proposed, that we offload
    our external Internet traffic to a local link with a price of about
    30% of similar capacity in private international connections. This has
    other business reasons like A) a need to be visible locally in Internet
    in this country, which has more nodes/capita in Internet than US and
    B) a need to access local customer and partner Internet services. That
    is now almost impossible most of the day due to the fact that all our
    traffic goes half way around the globe both through our network and
    through Internet. Existing European gateways wouldn't help much,
    because Internet connections from this country have a lot more capacity
    towards US than towards Southern France or Geneva. So far the response
    has been negative to our gateway request, because it's against
    corporate policy (defined by whom?).
    
    3) We have also heard, that there is no financing to any Easynet
    capacity increase at the moment. The story also is, that if any 
    financing is given, it goes to backbone. We are 2 hops away from
    the backbone so there is no hope even in the horizon. That means, that
    our order processing, delivery follow up, information retrieval etc.
    continues to be in difficulties. I see it almost a joke, that in a
    computer company, which claims to be strong in networking, the new
    PCBU SAP application requires that from this office (>300 people),
    we fax our orders to Stockholm, where they are fed to the system.
    Apart from the inconvenience and additional error possibilites there are 
    also costs related to double manual processing and additional 
    international phone calls. Also, there is a claim, that this
    application has dedicated links to garantee the response time. The fact 
    is, that that's only true for the backbone part. Majority of users
    are 1 or 2 hops away from the backbone behind overloaded connections.
    
    4) Despite the fact, that we seem to be incapable of purchasing
    sufficient capacity, many of our internal application designers
    seem to believe, that we don't need to consider our networking topology, 
    when the location of new servers is decided. New client/server applications
    are more demanding to response times than the old ones. Thus,
    application design and network topology design should go tightly hand
    in hand to garantee usability and to minimize the load on lines. I'm
    sure, that there are plenty of people, who understand these issues,
    but there seems to be a serious disconnection in discussions between
    different user groups, financing decision makers and service designers/
    providers.
    
    5) Increasing PC-networking (especially NETBIOS over TCP/IP) has made the 
    problem worse by loading the LAN with service broadcasts, which make smaller
    PC's occassionally almost inoperable and increase the response time.
    Proper research and design configuration/product selection guidelines 
    should be given to solve this part of the problem. This is a problem, 
    which I have seen in many customer cases as well, so it should be a vital 
    part of our MCS Network Services competence. 
    
    And re: to a previous comment about whining. Sending a memo to a CIO
    requires often more specific details, than what regular end users have 
    capability / time to give. After cuts in manpower we don't have know-
    ledgeable support people to cover all, when tools and practicies haven't 
    changed to cover the manpower loss. To buy quality service you still
    need to have people, who define, what you need and verify, what you
    get. ---and proper tools to do the job.
    
    --Ritva
    
    PS. I'm not in CCS, so I'm writing this as a service user.
    
    --Ritva

    Re .52:
    
    > 	Due to Digital's networking difficulties, Reader's Choice
    >	has been unable to distribute any messages for a 3-day period. 
    >	We apologize for the inconvenience.
    
    That's not a bug; it's a feature.
    
    
    				-- edp
    
    
Public key fingerprint:  8e ad 63 61 ba 0c 26 86  32 0a 7d 28 db e7 6f 75
To find PGP, read note 2688.4 in Humane::IBMPC_Shareware.

    
    	Heh heh.  8^)
    

re: .55

Very insightfull.

Well, I can say something about what this infrastructure costs us. 
(And yes I sent all this to my manager and asked him to shout about
 it)

We had a big demo for GE to show off our service tools. Too bad that
DSNlink couldn't even be run due to 100% packet loss as the systems
tried to reach each other over IP. Then when we tried our WEB interface
it died on timeouts trying to read some data over DECNET. Lets just
say that GE was rather harsh in their opinion of us. liesl

From what i can gather, the legacy infrastructure of VMS and DECnet has
only been pushed into further upgrades by the fear that we would lose
(Engineering) "support".  I think it has been recognized by all that the
future is IP and some combination of WNT and UNIX, at least for the past
couple of years.

The question is: "what is being 'supported' worth?"  I've met customers
who are still running RSTS systems without any DEC support contract
because they feel their technical people are sufficiently familiar with
the problems of supporting that environment to keep them hanging in
there until they migrate to the next platform-of-choice (which is most
likely going to be HP or Sun).  In our particular case, we have SAP/R3
on a UNIX platform in store for "corporate" applications and WNT/RAS
for desktops.  But the mirage of keeping "support" causes us to spend
untold dollars upgrading the dying VMS/DECnet legacy systems.  A saner
approach might have been to freeze this legacy environment at VMS V5.5
and DECnet Phase IV, given that our internal folks have supported that
combination for quite a while already.  Instead we seem to be counting
on promises of "support" from Engineering organizations that have been
gutted by lay-offs and left with a huge backlog of unanswered QARs.

Does this make sense?

- paul

    Hi,
    
    here in Rome Italy the situation is still very "unpredictable".
    
    Each morning you turn your PC on and wonder:
    
    "will I get TCP/IP, Decnet, None of them or both?  
    
    This morning for example we  get decnet only  + the standard problems of our
    LAN...
    
    Frankly speaking  the situation is hard to bear.
    
    I am not a Network expert at all but I suspect that most of our
    infrastructure has been built to run DECnet (may be even Phase IV) and
    occasionally IP while now is mostly running IP (for example the
    Notebook distributed under the Sales Workbench Program run IP only...)
    
    Listening to our network experts this seems to cause many different
    problems from the Local area to the wide area level.
    
    Since the network is vital for our work I would like to see a corporate
    level effort to tackle the problem and solve it even if this involves 
    drastic actions like phasing down DECNET.....
    
    Stefano Paccagnella
                                                                          

re .60,

> I think it has been recognized by all that the future is IP and some
> combination of WNT and UNIX, at least for the past couple of years.

The future may hold more TCP/IP than DECnet, but I don't think everyone will be
running only Unix and Windows NT.  And please don't tie OpenVMS and DECnet
together.  What does one have to do with the other?

> But the mirage of keeping "support" causes us to spend untold dollars
> upgrading the dying VMS/DECnet legacy systems.

You assume new versions of software cause more problems than old.  I don't
believe that is true.  And please don't call OpenVMS a "legacy" system.  Boy, I
hate that term, and never use it, especially in front of customers.

> A saner approach might have been to freeze this legacy environment at VMS V5.5
> and DECnet Phase IV, given that our internal folks have supported that
> combination for quite a while already.

And ignore all the rich new features of recent versions of OpenVMS?  Why? 
Ignore all the power of OpenVMS Alpha systems?  Why?

One of the problems in our infrastructure is the insistence on staying with
*old* versions of software, like ancient versions of VTX, and old versions of
OpenVMS and DECnet.

It sounds like you can do your job with old OpenVMS systems, or none at all.  I
can't.

Paul

    re .-1
    
    Well, if VMS wasn't there, NT might really be "New Technology"
    so let's all close our eyes and....
    
    8^)
    
    

And there is not a damn thing wrong with that...the work that is 
being doneon VMS is fantastic...I have actually changed my opinion 
of VMS of late...mainly because we are investing in it, and because 
of the NT Affinity program.

Now, I sure the hell wouldn't buy it over UNIX or NT but at least 
now I wouldn't dump it...I might even consider swapping my NVAX's 
in my 7000's for Alpha's.

*BUT* it's a very dangerous practice to concentrate on any of the 
things that are proprietary in the O/S.  And I'm sorry...DECnet is 
grafted to the hip of VMS.  Only the most forward thinking companies 
out there are smart enough to run VMS sans DECnet.

Now...let's say Digital came out in the trade press with a DECnet 
to IP migration program and announced that after a few years we will 
no longer support DECnet...

I *gaurantee* you...we would be applauded...obviously some people 
would be pissed, but frankly...it's about time we piss those people off...
we are too polite sometimes.

We woke up and got out of the database business...we woke up and got 
out of the text terminal business...we woke up and got out of the 
retail PC business.

Now....let's wake up and get out of the proprietary NOS business...
heck, maybe somebody will even buy it from us!!!

As always....JMHO  (reminder, I consider the 'h' to stand for 
honest...not humble...;^)

-Stephen

Re .64

>DECnet to IP migration program

not sure what you mean by migration program, but DECnet/OSI and *all* DECnet
applications happily run over IP already, and have been able too for some time
now.  You can even pick the provider of the IP software, it does not need to be
TCP/IP Services for OpenVMS if you already have software from another vendor.

Thus existing investment in applications is secure regardless of what transport
is used, and customers have the flexibility to chose future protocols and define
any migration strategy which is appropriate for them, as opposed to being
dictated by us.

fwiw,
--Scott

I don't understand what the griping about DECnet is about.  The network
problems I've been experiencing have been with TCP/IP only - DECnet works
fine.

					Steve

I hear ya...

In theory, it's a great idea...

Meanwhile, this is day 10 I can't fire up POLYCENTER DECnet
Manager on my NetView console because our 'remote' decDNS 
servers is still hosed.  Maybe when that's fixed I tone
my opinion down...right now, I'm having trouble seeing
the merits of DECnet/OSI.

Nothing personal.


-Stephen

(and I hear the sound of yet another customer eliminating DECnet
from their wire)

>problems I've been experiencing have been with TCP/IP only - DECnet works
>fine.


SAME HERE

But Stephen,  nothing I've seen in this string remotely suggests to me that the
issue being discussed is because of DECnet.  In fact, anecdotal evidence
provided by our co-workers would seem to suggest that DECnet is not at fault.

Neither have I seen any indication that DECDNS is at fault (the product).  In
fact, what I've seen and heard suggests that the real problem lies with the fact
that the company has continued to slash away at the EASYnet and its support
staff without any regard to the consequences.

But, since everyone loves to hate DECnet.....  Well, go ahead and flame. 
Meanwhile the real problem still exists and the situation does not improve.

Just my honest opinion.

--Scott

OK, that's actually a valid point...

But let me play devil's advocate here:

The very popular move to eliminate DECnet from corporate
networks all over the world is reality.  It's happening.

Also, when I talk to my coworkers, both locally and around
the world, the sentiment on DECnet is pretty unanimous.
I'm not the only one who feels this way...just perhaps the
only 'flamer' as you put it to post it in here.

Maybe it's a perception thing, or the company I keep...I dunno,
but a lot of very bright people and people who are a lot less
'tactfully challenged' than I am feel the same way.

This issue is larger than me and my flaming ways.

-Stephen

P.S.  send me the DECnet phase IV bits for Digital UNIX, would ya?

    As more anecdotal evidence, my experiences lately have been:
    
    DNS (BIND) has been very reliable; decDNS has been the pits.
    
    IP connectivity has been flakey; DECnet connectivity has been solid.
    
    Throughput/performance of both network stacks seems to vary greatly
    on an hour-to-hour and day-to-day basis, from the pits to excellant.
    
    Dave

    Stephen,
    
    Let's stop the o/s and protocol flames.  The real legacy is the person
    that's not willing to listen or to try new things.  What's the purpose
    in asking for "phase IV" anyway?  OSI works on Digital UNIX just fine,
    thank you.  TCP/IP shows up on more and more OpenVMS systems, inside of
    Digital and out.  Our customers have a choice, and we should be proud
    of that.
    
    Mark

I think we are confusing an applications use of the network, with the network
itself.

I have a TCP/IP application that insists it be able to reach a DNSbind server;
it cannot.  Therefore TCP/IP sucks and should be junked.  We should abandon all
efforts in the TCP/IP space, and tell customers immediately that we will no
longer support TCP/IP.

I have an application which relies on DECDNS, and insists that it be able to
contact a DECDNS nameserver; it cannot.  Therefore......

Am I missing something here?

What?  You mean to tell me that in both cases the problem was because someone
placed a misconfigured router on the network, and the people that would normally
have either prevented this from happening or diagnosed the problem in a timely
fashion were TFSO'd, and that the problem didn't need to be so bad except that
we centralized a lot of our routers and downgraded our comm circuits from T3 to
T1.  I am simply aghast.  Well, it's obvious to me that this happened because of
DECnet!  Death to DECnet!!!  Hanging is too good for something that slithers on
the ground like DECnet!!!

Here's an interesting datapoint shared by one of the DECDNS engineers.  CERN has
a very large and complex network. CERN uses DECnet (as well as probably
everything else).  CERN has a DECDNS namespace which is as large and maybe
larger than ours.  CERN's namespace does not go into meltdown every quarter. 
Why is that?

--Scott

    .64 Stephen,
    
    After reading this entry of yours I couldn't help thinking of what
    happens if we "wake up someday and we're OUT of business"? ;-)
    
    

This is hopeless anyway.

I can't ever get conjecture going on an issue here without
it turning into a rathole about who is flaming who.

Finally, DECnet/OSI on Digital UNIX does not work for us...in fact
it's hosed more often than not.  I'm sitting here doing this
when I should be finishing my NMS setup anyway.

hmmmm....maybe I can figure out a way to run without DECdns...

Looks like it's time to start hacking away.  What else is new.

*vapor*

>    Let's stop the o/s and protocol flames.  The real legacy is the person
>    that's not willing to listen or to try new things.  What's the purpose
>    in asking for "phase IV" anyway?  OSI works on Digital UNIX just fine,
>    thank you.

If you happen to manage a Digital UNIX system in your free time (as I
do), DECnet is a ROYAL PAIN!!!  Why do I use DECnet?  Because I have
to use it to get to systems in this corporation that only run DECnet.
Having administered DECnet Phase IV for years on ULTRIX, then on
migrating to Digital UNIX having to learn a COMPLETELY DIFFERENT
management scheme courtesy Phase V, just to adminster DECnet is a
COLOSSAL waste of my time.  Especially, since the skills in adminstering
Phase V have ZERO value in my Consulting role with customers, who are
running from DECnet Phase ANYTHING as fast as they can!

Looking forward to the day when I can type:
	setld -d `setld -i|grep DNA|grep installed|awk '{print $1}'`
to rid my system of all DECnet subsets!

Ram

    I'm glad to see this string here.  And even happier that some of you
    appear to be taking your concerns about the inability to do your jobs
    when the net is broken to your management.  Over the past several years
    we (CCS) have had "cut costs" as our main marching orders.  Whenever
    any proposal to SPEND money in order to improve service (or protect it)
    has been made, the finance mentality has been to show an enormous
    internal rate of return or it doesn't get done.
    
    What has been (largely) ignored by the powers that be is that
    investment in the infrastructure is generally STRATEGIC, which means
    that it is often a matter of corporate survival at stake rather than
    just what the proposal will save compared to some other action (often
    "do nothing").  
    
    We have all been guilty of taking the infrastructure for granted at one
    time or another (especially when it is "invisible" because it works). 
    I have often seen people here talk about wanting to install mega
    bandwidth to solve "problems", seemingly ignoring the fact that such
    capacity costs big money, which has not been available to the company
    in large quantities over the past few years.  I'm NOT arguing that
    having large numbers of people sitting around waiting for the net to
    respond is also not expensive (and probably costs more than the cost of
    up-grading the net), just that there is not a hugely visible bill for
    it coming in each month.  It is easier to pick on obvious expenses than
    on hidden ones.
    
    IMO, the CCS organization has done an incredible job over the past few
    years keeping the infrastructure going in the face of continual demands
    to cut expenses by up to 25% per year!  We've added capacity while
    cutting costs.  But now the crunch is getting
    awfully near, demands on the networks are exploding even as the
    requirement to cut expense continues.  In my nearly 17 years of
    experience here it sometimes has appeared that the best way to get the
    resources to "improve" the infrastructure is to let it "break", at
    which point "whatever it takes" goes into overdrive until things settle
    down a bit.  Then the whole process starts over.  It's a heck of way to
    run an infrastructure...
    
    Bill

    
    	Just as an FYI our Network people here in HLO Hudson Ma., Were told
    that the DNS problems were fixed late Friday March 1st. Yet, according
    to this notesfile people are still having problems.
    
    Ron

    Ditto .76:
    
    >Especially, since the skills in adminstering Phase V have ZERO value in
    >my Consulting role with customers, who are running from DECnet Phase
    >ANYTHING as fast as they can!
    
    **NONE** of my new customers are running DECnet and all the "old" ones
    are either have eliminated or are eliminating DECnet from there
    networks.  We need to wake up and get with the program and start by
    providing an Easynet "Notesfile" listing based on IP hostnames...
    
    John

> We need to wake up and get with the program and start by providing an Easynet
> "Notesfile" listing based on IP hostnames...

Not all Notes conferences are available via both DECnet and TCP/IP.  Not all
Notes conferences available via TCP/IP are announced as such in the
EASYNET_CONFERENCES conference.

Most access to Notes conferences on node HUMANE comes over DECnet.  I'd guess
that one or two per cent come over TCP/IP.  Even the Sales Workbench systems
(the laptops given to sales and sales support folks) use DECnet for their
connection to Notes conferences.

That said, I think TCP/IP access information should be made available so users
could choose either protocol.  The problem is getting the information about
which Notes systems make their conferences available via TCP/IP.

Paul

> Most access to Notes conferences on node HUMANE comes over DECnet.  I'd guess
> that one or two per cent come over TCP/IP.

This is a critical mass issue.  Since the majority of nodes offering Notesfiles
either do not offer IP access or do not advertise the IP access, what does a
poor field user like me do: continue to use legacy DECnet.  When machines
offering services on the Easynet switch to the following:
	o all services to the extent possible available via IP
	o services via legacy DECnet is optional
then you will soon have critical mass, and you can be sure that a very
small minority of users will come in via legacy DECnet.

> Even the Sales Workbench systems
> (the laptops given to sales and sales support folks) use DECnet for their
> connection to Notes conferences.

As a Sales support person who uses the Sales Workbench daily, this is a
MOST misleading statement.  The Sales Workbench (thank God!) has NO legacy
DECnet on it.  These PCs talk IP to a Notes Gateway such as NQOS01, which
then uses legacy DECnet to talk with the Notes server.  This is the reason
that the poster is identified by strings such as
	NQOS01::nqsrv302.nqo.dec.com::Rao
Note the IP address assigned by the DHCP server to the Sales Workbench PC.

Ram

>Most access to Notes conferences on node HUMANE comes over DECnet.  I'd guess
>that one or two per cent come over TCP/IP.  

This is a VERY misleading statement.  I remember YEARS ago, in the "one company
one network strategy" days, someone in NaC did a market survey to see if that
thing called TCP/IP was really worth paying attention to.  They asked all our
customers (mostly DECnet types) if they thought TCP/IP was important and since
they were all happily running DECnet, they said NO!  Therefore the conclusion
was that TCP/IP wasn't important. 

My point it's difficult to use TCP/IP to talk to notes so most people use
DECnet.  Don't assume they want to or love it, they HAVE to!

As we speak, I'm running NOTES on a VMS machine, but I've telnet'd in from my
PC, which doesn't have DECnet anywhere near it...

-mark

I'm sorry if my statements were misinterpreted.

re .81,

Yes, I know the Sales Workbench laptops use TCP/IP and not DECnet.  My point was
they use a server that uses DECnet to then access conferences.  This is what
works today because not all conferences are available via TCP/IP.  I can't
imagine why a laptop user would care what protocol the server uses to speak to
the Notes system.

re .82,

When I pointed out that about two per cent of Notes access to node HUMANE came
in via TCP/IP, I wasn't trying to say DECnet is better than TCP/IP or vice
versa.  Hey, look, I use both DECnet and TCP/IP in my daily work and can't
imagine why we'd want to get rid of either one.  Use what works.

I'd love to add valid TCP/IP access information to EASYNOTES.LIS.  Short of
writing a program that tried accessing every conference via TCP/IP, I don't know
how we'd gather that information.

Paul

    Note .65 says
    >not sure what you mean by migration program, but DECnet/OSI and *all*
    >DECnet
    >applications happily run over IP already, and have been able too for
    >some time
    >now.
    
    If notes is a DECnet application, and previous notes seem to say so,
    then surely it must run over IP without any problems.  So why do we
    need these notes gateway things?  
    
    

Notes does run over IP.

I don't understand this religious war against DECnet.  DECnet provides far
more functionality and transparency than TCP/IP for file-oriented applications.
As a system manager, I find DECnet easier to manage than TCP/IP (which
provides so many opportunities to screw up some setting or other.)  But
I use both, each in its area of strength.

I'll also repeat something I said earlier.  I don't understand why some people
blame DECnet for our corporate network woes when it's been TCP/IP that 
has been consistently broken for me.

					Steve

   re: DECnet works
   
   Wrong.  It may be working for you, but for many of us in the Dayton,
   Ohio office are having lots of problems.  Not only with our local
   machines, but with ACISS2:: (where ever that is).
   
   VTX simply refused to connect to anything last Thursday and Friday. 
   I sent VAXmail from my local machine to several other remote nodes. 
   Nobody got the mail, and I received no notification that it failed. 
   We got many "host not available" errors bouncing around (one minute
   they're there, the next they're not).  Connections drop in notes
   sessions, etc.
   
   The only protocol I don't know if it's working or not is LAT since I
   don't use it.

Re: .86

Whatever problems you're having would likely affect TCP/IP as well.
I don't see how that's DECnet related.

			Steve

Re .84 and .85

Perhaps I should clarify something with regard to DECnet applications and IP.

NOTES is a multi-transport application, in that it can be configured to use
DECnet or TCP/IP (or both).  Not all DECnet applications have this ability. 
With the more recent releases of DECnet/OSI though, any DECnet application can
run over TCP/IP using RFC1006+  (my connection to the EASYnet is via a SLIP
line, and I frequently SET HOST over TCP/IP into some systems back east).

We need gateways when you need to go from on protocol environment to another.
Any systems that are running DECnet PhaseIV and not a TCP/IP stack, would
require that a TCP/IP user go through a gateway.

fwiw,
--Scott

    From my experience well-run customer networks intgrating DecNet OSI and
    TCP/IP work well. Singel Simple DecDNS servers also work well. Dns has
    always had the biggest impact from it's bug's.
    
    Gullik
    

> I don't understand this religious war against DECnet.  DECnet provides far
> more functionality and transparency than TCP/IP for file-oriented applications.
> As a system manager, I find DECnet easier to manage than TCP/IP (which
> provides so many opportunities to screw up some setting or other.)  But
> I use both, each in its area of strength.

I beg to differ.  In my work environment, where I use legacy OpenVMS
as little as possible, IP is a whole lot more functional than legacy
DECnet. (The story may be different if you are married to legacy
OpenVMS.)

With regards to management, IP with its hierarchial name-space is so
much easier to manage than keeping a legacy DECnet nodes database
up-to-date.  Things are probably better with legacy DECnet Phase V, but
I don't have the motivation to invest more in learning legacy management.

As a technical nit, in my 6 years of being an Internet domain adminstrator,
I have spent 0 seconds managing TCP/IP; it hasn't needed management, TCP
simply runs over IP and that's that.  It is IP that needs to be managed,
with its routing, and name-space etc.  Please be precise as to what you mean.

Ram

        The problems don't seem to me to be Protocol related anywhere.
        They are IFRASTRUCTURE releated. If they were protocol related
        then it the best spirit of engineering they would be 'fixed'. I
        think that there are too many protocols sending too many packets
        to too many different routers/bridges/brouters etc onto a wan
        backbone structure that is set up to handle 1990 era networking
        not 1996 era networking. 
        
        Think about it. In the past most of the traffic was lat based to
        DECnet hosts. Then there was DECnet traffic for NOTES, VTX, file
        transfers etc. A few rouge elements ran them Unix boxes and did
        that TCP/IP thing. Even the few PC's ran DECnet and Lat
        
        Now today. PC's run TCP/IP, There are very few Lat connections
        except for those few individuals stuck on terminals and Dial-in's.
        The DECnet traffic for NOTES, VTX and file transfer is about the
        same. But NOW there are Significant numbers of TCP/IP based
        systems running Unix, VMS, NT and Windows. 
        
        In the past year there have been AT least 200-300 new WEB servers
        set up inside Digital (ALL TCP/IP) the load to go outside the fire
        wall has gone up at greater than Geometric proportions and as each
        new Hot App gets created it will go up more. 
        
        A year ago I had probably stuck my nose outside of the firewall
        Maybe 10 times total. Today I do that in the first 5 minutes I am
        logged on in the Morning. 
        
        The powers that be have not taken this fundamental paridym shift
        in the use of the network inside digital into account in their
        planning or budgeting. 
        
        It doesn't do any good to point fingers at one protocol or another
        what is broken is the fact that every single employee in digital
        has fundementally changed the way they work with the network in
        the past year. IF management doesn't recognize this fact and take
        it into account then the problems will persist and get worse. 
        
        What is needed is a message stating to management that this
        fundemental change has occured and that a reevaluation must be
        done immediatly and changes institued to handle this. 
        
        My suggestion would be that someone in the IPO work this issue as
        it is truely and Internet paridym shift that is happening. And if
        we (digital) can address this then we might be in a position to
        help our customers when it happens to them. 
        
        

Re: .90

You use "legacy" as if it were an insult (which I suppose it is meant to be.)
There's nothing wrong with systems that work and do what you want them to.
Especially when they're so reliable you can just forget about them.

Each week I have to figure out why the IP name servers for my site suddenly
forget everything, why SMTP mail goes into a black hole never again to emerge,
etc.  As for DECnet, I set it up several years ago and have not had to do
anything to it since.

I can understand that if your primary environment is UNIX, then DECnet is
a pain.  The integration and transparency that exists on OpenVMS just
isn't there on UNIX.

				Steve

this last comment got me thinking...

>        My suggestion would be that someone in the IPO work this issue as
>        it is truely and Internet paridym shift that is happening. And if
>        we (digital) can address this then we might be in a position to
>        help our customers when it happens to them. 
        
In the past, the thing that made us so successful was that we were always a few
years or more ahead of our customers and nobody knew more about what our 
customers *would* experience than us, since we experienced it first.

In more recent years, it seems our customers are several years ahead of US and
perhaps we could learn from them.

I'd like to hear what some people who touch REAL customers know about this.  Are
there some reference customers who have already gone through what we are now
going through?  If so, what did they do about DECnet & TCP/IP co-existence?  Did
they simply pick one over the other?  Did they segment their network by 
protocol?  Did they just throw more bandwidth/hardware at the problem?  While
we're at it, how many picked our approach of reducing bandwidth/staff in the
hopes that it would *reduce* network usage?

Perhaps if we CAN learn from some of our customers who have been with we WILL
be in a better position to help the rest of our customers who haven't figured
it out yet...

-mark

    With regards to the OSI changes and associating them with 
    OpenVMS in this string:
    
    OpenVMS has had nothing to do with the routing changes being 
    inflicted on Easynet save that OpenVMS does have an OSI stack.
    
    For the record I have in this notesfile questioned the wisdom
    of migrating to OSI, questioned why we are angering our relatively
    loyal DECnet IV customers, and I have praised OpenVMS's initiative
    to become "networking protocol" independent.
    
    With that said:
    
    In the past I have never had any problems with DECnet Phase IV, 
    no corruption, no strange network activities.
    
    In the Present TCP/IP has started to become my primary communications
    protocol for OpenVMS, WNT, and Unix and continues to improve and even
    become more funtional (from an application standpoint) then DECnet or
    OSI to me and more importantly to my customers.
    
    Antidotally, DECnet changes on Easynet have begun to cause outages
    and even corruption of files during a simple copy between phase IV and 
    phase V DECnet for me.
    
    I'm very sorry to inform the DECnet team(s) but when I can have a .ZIP
    file pushed and not pulled (because pulling causes corruption), with a 
    shipping network product from Digital I no longer can keep the faith 
    for our product... (And don't tell me to report the bug, I have enough
    problems keeping up on TCP/IP and my other duties that help Digital 
    make money in our customer base)
    
    OSI is dead, TCP/IP and it's followons (Version 6) will be the winner
    in the marketplace.  Let's let phase IV die a dignified and useful
    death and not try to keep it incarnate in Phase V/OSI.
    
    This is about money, customers, and things that work and interoperate
    in the marketplace.... TCP/IP has won... Let's all get on the same
    bandwagon as our customers...
    
    If you want someone to blame... Digital should sue the U.S. government
    for all the research and development dollars spent to develop OSI to 
    their request (I still remember 1993 as the deadline for OSI and
    Digital was the only one with a full OSI product...Feds and local 
    governments backed away from that deadline in favor of TCP/IP leaving
    us with 8+years of R&D...)  But we won't sue ... Too much business 
    at stake with the Feds right?  I bet SUN would ask for the money...
    
    Billion dollars here, billion dollars there.. pretty soon you're
    talking about real money...
    
    JMHO
    
    John Wisniewski
    
    
    

Look,

I'm glad to see that the issues are beginning to surface here...

The problem is that bandwidth is so precious these days, we *MUST* standardize
on one protocol.

And that protocal *SHOULD* be TCP/IP.

Someone asked for an example of a customers experience with this and whether or
not they chose to pick one over the other or co-exist.

Give Microsoft Network Engineering a call.

-Stephen

    re: .93
    
    ...they (the customer) "dumped" and are continuing to "dump" DECnet.  New
    customers won't even talk about DECnet.  I agree with .94, stop
    wasting money on any DECnet product (Phase IV or V), TCP/IP has won...
    
    John

> The problem is that bandwidth is so precious these days, we *MUST* standardize
> on one protocol.

Could you please explain why this is true?

In my experience, for an end node system, DECnet/OSI is more robust and easier
to manage than TCP/IP.  Until TCP/IP stops forcing me to deal with such
difficult tools such as FTP, and I can copy files using TCP/IP protocols as
easily as with DECnet, I can't say I'd favor TCP/IP for anything except for
accessing the World Wide Web and newsgroups.

Use what works.  We shouldn't have to give up DECnet or TCP/IP.  Both should
work.  The Easynet infrastructure problems should be fixed, so we don't have to
argue that "my protocol is better than yours".

Paul

>    ...they (the customer) "dumped" and are continuing to "dump" DECnet.  New
>    customers won't even talk about DECnet.  I agree with .94, stop
>    wasting money on any DECnet product (Phase IV or V), TCP/IP has won...
    
To make these kinds of statements more real, is it possible to go into more
details about who, $$$, etc?  Are these big companies, little companies or both?

From a technical perspective, we can easily get just as many people saying we
should keep both as well as those who believe we should dump DECnet in favor of
TCP/IP.  Does any want to go on record with the third possibility of dumping
TCP/IP and favor of DECnet?  8-)  just trying to be complete...

The argument that's going to win (if there really is such a thing as a winner)
is the financial one.  What as the $$$'s involved with both cases?  Who has
done it already and demonstrated its worth?  That's why I think we need some
real references.

-mark

> The problem is that bandwidth is so precious these days, we *MUST* 
> standardize on one protocol.
 
This seems to imply that multiple protocols create greater load by their very 
existence. With the exception of routing updates and the like, that's a bit 
hard to substantiate. If I'm transferring a file, and I have my choice of both 
DECnet and TCP/IP (or UDP if I'm using NFS), I don't decide to move the file 
twice, once with each protocol, and then see which file I like better. I move 
the same bytes once, with whichever protocol makes sense in context.

    Is OSI not bigger (installed base) in Europe (elsewhere?)?
    
    d.

>    Is OSI not bigger (installed base) in Europe (elsewhere?)?

With the explosion of WWW, if this was ever true, IP will soon be
several orders of magnitude bigger than OSI (as it is today in the US).

Re: .92

> You use "legacy" as if it were an insult (which I suppose it is meant to be.)
> There's nothing wrong with systems that work and do what you want them to.
> Especially when they're so reliable you can just forget about them.

I do not intend legacy to be an insult.  I use the word as a "wake-up call"
to the many people in Digital, that that is how the real customer world
outside of Digital views DECnet.  However comfortable we inside of Digital
may be with DECnet, the world has passed it by.  And as you say, legacy
systems are so reliable that you can just forget about them (and put your
infrastructure dollars elsewhere on strategic stuff!)

> Each week I have to figure out why the IP name servers for my site suddenly
> forget everything, why SMTP mail goes into a black hole never again to emerge,
> etc.  As for DECnet, I set it up several years ago and have not had to do
> anything to it since.

I have worked twelve years in Digital, all in a predominantly IP
environment.  The first six were in MKO/ZKO where I had such a robust
IP environment that I rarely had DECnet on my workstation, and always
had SMTP as my prefered mail protocol.  The last six have been in the
Indianapolis Digital Sales office, where I have run the IP network (in
my free time) and it just hums.  (It has been 5 years since I hacked
by sendmail.cf or my MX records significantly.)  Your problems with IP
are probably due to network administrators who are too
DECnet-encrusted to comprehend IP management.

My business card reads "ram@ini.dec.com" and I daily interact with customers
reliably with this address.  Outgoing mail from me is seen by the customers
as coming from "ram@ini.dec.com".  This is in compliance with Corporate
security by not revealing a node name, which I believe is impossible to do
in the Mail-11 world.  And I don't have to worry about any DECnet mail
gateways.

Ram

re .100

>    Is OSI not bigger (installed base) in Europe (elsewhere?)?

In comparison to what?  In comparison to the U.S., yes, it's probably safe to
say we have more customers in Europe and Asia using OSI, and especially OSI
applications (I base this on where I see IPMT cases coming from for FTAM).  In
comparison to TCP/IP, OSI has a smaller installed base just about everywhere I
can think of.

--Scott

back to your regular program...

Geesh, when will I ever learn?

Fine.  OK.  I get it now.  We will just kill it at our site.  Then somebody else will.
Then yet another site...and another site...

If we are lucky....we'll get rid of it by the year 2065.

Right.  About that time the last OS/2 user will have given up too.

Ah well...

We've beat this horse to death I guess.

-Stephen

Re .104; I'd still like to hear how you arrived at the conclusion you posted in
.95.

Surely you can do more than make sweeping statements and then claim that the
proof is self-evident.

--Scott

    This is purely antidotal, totally subjective but as I look around 
    North Texas and Oklahoma (and I only deal with 400+ customers 
    from the DECUS DFWLUG) and I only see two customers using DECnet V
    and all the rest have/are/will migrate from DECnet IV to TCP/IP 
    when they are able to.
    
    My numbers tell me that I better have a TCP/IP product set to sell
    to these folks or I'm out of the networking business.  
    
    They will not buy OSI/Phase V...They don't want to upgrade into it,
    they don't want to install it.. Period, End Of Story.
    
    As to the Ease of use with dir, copy, edit and the other DCL commands
    with DECnet (vs FTP, telnet, etc), part of the OpenVMS decoupling
    of network transport from the OS promise that type of transparent
    access across TCP/IP protocol too, it's an application thing (just
    like FTP is an application..).  And we're seeing the beginings
    of that integration in V7.0 of OpenVMS...
    
    But if I'm a customer, I get a choice to either use a ballpeen hammer 
    on my right hand or to manage 4,3,2 or a single network protocol...
    guess I have to choose a single protocol and look for the market leader
    so that I can settle on one skill set for my people...
    
    DECnet OSI provides no added value in the marketplace above what 
    customers want today and OSI does this at a premium price (for 
    equipment, training/retraining, and grief...). 
    
    I don't see a need for OSI from my customer base in Dallas but we only 
    have 27 fortune 500 HQs in this area, most have a TCP/IP migration 
    plan in place and have been working those plans for years... Someone 
    from NY or PA want to tell us about OSI's successes in your markets.
    
    Or maybe we should hire a consulting firm, pay them millions of dollars
    and poll our installed base... Then we'd really know what kind of 
    network protocol we should be moving twords for our company...
    
    Or read the trade mags, airline mags and even the color supplements...
    Only see TCP/IP articles... must be a trend...
    
    After Europe is surrounded/innundated by the Internet we'll see how 
    long they cling to OSI...
    
    Fights over, game lost, recover and let's move on to something
    customers will buy and we can all use...
    
    Of course I may be wrong and some OSI marketing team from hell is 
    right on the verge of selling most of the free world on why 
    there should be multiple protocols, and why they shouldn't be
    using TCP/IP...
    
    
    During the 1980's when DECnet and SNA were loudly gutting themselves 
    arguing about who was the best, Ethernet VS Token Ring, and what arch 
    was better or had better grandparents, TCP/IP quietly took over the
    customer's mindshare not because of superior technology, but because
    the specification was public, free, and did most of what they wanted
    to do... (by connecting systems to network resources).  
    
    This shows a very important point of raw capitalism:  Something
    that's free and does "Something -Like" it's more costly competitor
    will win in the marketplace.  
    
    Hello... DECnet V/OSI people... Wake up...Smell the coffee...
    Digital in 1996 does not have the resources to deliver two 
    products that do exactly the same thing... Our customers 
    don't have the resources to buy two things that do the same
    thing either...Particularly when OUR thing costs more and 
    does things that our customers don't want to pay for...
    
    
    JMHO,
    
    John Wisniewski
    
    
    

Scott,

I'm sorry that this is hitting you where it hurts.  I really am.

This issue is not about my personality or about my 'sweeping statements'.

It's about Digital's turn around and about the need to continue to purge 
ourselves of legacy thinking and legacy applications, that, or the need to
re-engineer our products that are legacy to fit into the new technology 
paradigm, and the success of that re-engineering.

I'm a System Manager...this stuff effects me everyday.  I don't really care 
what the nuts and bolts reasons are for things that don't work...when they 
don't work a lot...when I have to spend hours and hours and hours on 
something trying to get it to work, and it still doesn't work...eventually 
I just throw it out.  I still can't bring up my DECnet Manager on my 
Network Management Station because of some broken DECdns server at some 
site that I have no control over...but IP just works...like electricity...
I plug stuff in and it powers it, and it's easy to manage...no, it's
like really *fun* to manage.  Now, I'm either gonna manage DECnet,
or kill it...there is no way I'm gonna let it run on my wire without
being aware of what it's doing.

Now right about here is where I get the speech about the fact that it's
not the technology, it's the process that's broken.  I've been around a
while now, and I know better than to start screaming for Digital to throw
millions of dollars of hardware at this problem.  To me, the much easier
solution is to just kill the problem...in this case DECnet.  And oh
by the way, my peers out there at other shops came to the same conclusion.

Now, is there a technical solution to all of our problems?  Well, yeah
there probably is...do we have the time or the money to pursue this?

The answer is a resounding *NO*!

Again, no matter how much you guys want to get pissed off at me, the 
noter (assuming I'm pissing you guys off)...the facts remain.  
DECnet is going away...the sooner we at  Digital accept that, the sooner 
we can get on with our lives, and kill it off of our own network.

That is all I am saying.  This is a strategic statement.  So if you
think I'm gonna get into a techincal discussion about the merits of
DECnet, you're not getting what I am saying.  Beta was better than
VHS, the MAC is better the Wintel, and on and on...but that's not
really the point...

-Stephen

    >Digital in 1996 does not have the resources to deliver two...
    
    John,
    
    Are you sure you want to go with that argument?  I'm sure that I can
    think of some other areas where it might be applied.
    
    Mark

    To quote .106: 
    "This is purely antidotal, totally subjective but as I look around"
    
    Florida and I see **no** customers running DECnet Phase V and the one
    or two (NASA) using Phase IV are not upgrading to Phase V and/or
    eliminating Phase IV in favor of TCP/IP.  All the new customers I
    encounter (most using Digital Unix AlphaServers) are primarily using
    TCP/IP and a couple I've talked into using Digital Unix LAT for
    controlling serial printers hanging off DECservers. From a customer
    perspective DECnet (either flavor is dead) is dead!!!
    
    John

The gentleman from Indiana (the Hoosier State) reports No sightings
of OSI in the state.  One of the largest customers from this state
is working feverishly to transition their sizeable Mail transport backbone
off DECnet Phase 4, and onto IP

Re .107,

>I'm sorry that this is hitting you where it hurts.  I really am.

This doesn't hurt me.  I could personally care less, but thank you for your
concern.   I'm mainly interested in understanding the antipathy toward DECnet
and OSI.  I'm interested in understanding why people feel that "one size fits
all." - and to some degree, why it seems to be the pro-TCP/IP people that are so
insistant of this.

>This issue is not about my personality or about my 'sweeping statements'.

My apolgies if that's what I sounded like.  You made the statement that network
bandwidth is limited, therefore we should only have one protocol and that
protocol should be IP.  What I wanted to know is what data you based that
conclusion on (since none was provided).  Information in this string would seem
to suggest that your premise of limited network bandwidth is not valid.  Even if
the premise was valid, the conclusion still seems to be a nonsequiter.

Re later entries regarding "sightings" - I can point to almost as much data from
a worldwide perspective that says customers are buying OSI, are using it, and
it's leveraging significant $$$'s in sales for us.  On a worldwide perspective,
we have customers buying TCP/IP solutions from us as well.  That's great!  We
can provide a networking solution for whatever networking problem our customers
need to solve.

  I'll try putting some words in Stephen's mouth, and he can report
  back on how well they fit.


> ...limited bandwidth...

  Well, I don't know if running n protocols on a wire/WAN/whatever
  requires much more bandwidth than running one, but I know *MY*
  bandwidth is *QUITE* limited, and juggling n protocols in my
  brain requires more than n times as much effort. After all,
  besides remembering the n different sets of architectures and
  utilities, there are then all the *INTERARCHITECTURE* issues.


> ...nobody loves DECnet...

  Hey! I love DECnet Phase IV! It was wonderful and is still good
  technology. If the world wanted DECnet-IV, I'd be glad to promote
  it forever. But the world doesn't want DECnet-IV anymore.

  And DECnet-V is a mess. It's an architecture done by committee,
  and it shows. Everybody's "behind it" but nobody's "buyin' it".

  They're buying TCP/IP. It may be VHS, not Beta, but they're
  buying it. And if anybody doubts it, why not post some stats
  showing number of installed nodes worldwide running the various
  protocols. AppleTalk, Novell-3, Novell-4, IP, DECnet-IV, OSI,
  SNA, ARCnet, whatever.

  Among the three we're debating (DECnet-IV, OSI, and IP), IP'll
  be the clear winner. And that's all we should care about.

                                   Atlant

re: IP vs DECnet

In this forum it is a moot point at the moment. If you re-read some of
the earlier replies *both* protocols [on the Easynet] seem to have serious
problems at the moment. I'll take any network that works!

IP seems to have the most problems, though I expect that it's a victim
of it's own success. I was having a lot of trouble reaching even
internal web pages this morning (at 7am EST).


M

[I'm typing this in from Palo Alto into a system in LKG and this is worse
than a 2400 buad line.]

The DECnet/OSI products are pretty much frozen in functionality.
Most of the effort is in remedial support.  That's the way it 
has to be to not drive away those customers who are spending money 
on DECnet.

It's a no-brainer to see that the world is heading to IP.  But
within five 5 years the current IP infrastructure will be 
hitting a wall.  Either the Interent will converting to IPv6 
or NATs (Network address translators) will be widely deployed.
The former will require another Phase IV --> Phase V type
transition effort (but worldwide in scope); the latter will 
subdivide the entire internet will in hidden areas.
Pick your posion.

---

We have an invertebrate network.  No matter what protocol you use,
the network can't support it.  Until we have a reasonable network
backbone it will remain almost unusable.

Thanks Atlant.

OK...let's separate the issues:

1. Network bandwidth on our WAN in general

2. DECnet Phase V problems/bugs, IS to IS routing

3. TCP/IP problems reported here, though our site has none
   unless you count packet loss, see issue number 1.

4. Strategic directions of our customers, i.e. killing
   all forms of DECnet, should Digital do the same?

5. Whether or not two protocols on the wire chews bandwidth...
   would the elimination of DECnet off of our wire increase
   our overall bandwidth?


Issue number 2 is still affecting me.

Be interested in hearing opinions on the other issues, or
even if you guys think that's all the issues we are
discussing here.

-Stephen

>[I'm typing this in from Palo Alto into a system in LKG and this is worse
>than a 2400 buad line.]

Now would that be because you telnet'd from PA into LKG?  tch, tch, tch.  That
character echo will kill you every time.  Tried doing a MODE LINE?  ;-)  Maybe a
more suitable protocol could be found?

RE:.109

Against my better judgement to jump in here..

>    Florida and I see **no** customers running DECnet Phase V and the one
>    or two (NASA) using Phase IV are not upgrading to Phase V and/or
>    eliminating Phase IV in favor of TCP/IP. 

I know for a fact that you have at least 2 large (subjective measurement)
DECnet/OSI customers based in Florida. We measure "large" by the number of
licenses, or the nodes.

RE: .110 - you have a large DECnet/OSI installation as well, but the account is
managed out of Colorado.

RE: .112

>   And DECnet-V is a mess. It's an architecture done by committee,
>   and it shows. 

While there are certainly parts of DECnet-V that are less robust that is
desireable, and parts of the architecture leave much to be desired, DECnet Phase
V includes DECnet Phase IV - a point often overlooked. That is to say that a
Phase V end system behaves on the network like a Phase IV end node in a Phase IV
network. What has changed is the management interface and the code base, as well
as the addition of the OSI stack. And as of V6.0 of DECnet Phase V, DECnet
applications can run unchanged over TCP/IP.

How do you think the IPV6 design came about? If committee architecture is a sole
detracting factor, we have many things we would pitch the same time we pitch
DECnet. Starting with that thing called "OSF"...

>Everybody's "behind it" but nobody's "buyin' it".

Have you seen the numbers for the DECnet products? You wouldn't make that
statement if you had.

RE: .115

> OK...let's separate the issues:
[...]
>2. DECnet Phase V problems/bugs, IS to IS routing

Yes, let's separate the issues. This one item alone has been discussed ad
nauseum and can be separated into several different issues:

a - Problems with the IS routing backbone, management.
b - problems with the DECdns product
c - problems with the Digital DECdns namespace; management
d - problems with the DECnet Phase V on OpenVMS product
e - problems with the DECnet Phase V on Digital Unix product
f - problems with the DECnis product
any I left out?

I submit that the majority of the problems you have seen fit into "a" and "c",
and a minority of of your problems include some "b" and "d". (pardon the pun)
But you lump them all into one and wish to rid the corporation of what you
perceive to be the problem: DECnet. Too bad that isn't reality. 

You are aware that IP was down in LKG for two days last week? What's the matter
- isn't the TCP/IP protocol suite robust? there are far too many problems with
TCP/IP for us to bet our business on it and have us continue to have problems
like this. See how silly that generalization sounds?

>4. Strategic directions of our customers, i.e. killing
>   all forms of DECnet, should Digital do the same?

If you "kill" all forms of DECnet, you will "kill" a significant portion of
profit this corporation makes. Last I heard we were in business to make money.

Matt hit the nail on the head - noone denies reality about the Marketplace, the
market is definately in the TCP/IP camp, but why are you so intent on killing a
serious cash cow that has several years left on it?

>5. Whether or not two protocols on the wire chews bandwidth...
>   would the elimination of DECnet off of our wire increase
>   our overall bandwidth?

Do the study and present us with the information you accumulate. But will it
change anything? I doubt it. The root of our networking problems is money spent
on the corporate infrastructure, not any one product, not any one protocol. You
can continue to deny it, or divert from it, but that is the sad reality.

Bryan Williams

> >Everybody's "behind it" but nobody's "buyin' it".
> 
> Have you seen the numbers for the DECnet products? You wouldn't make that
> statement if you had.

  Prove me wrong. Post the numbers of nodes.

  We've killed lots of cash cow so far, in the stated interest of
  investing for future growth. It's long past midnite for OSI, and
  the last meal has been ordered for the condemned.

                                   Atlant

re: .117

Nobody has suggested that we stop selling legacy DECnet to customers that
want to pay good money for it.  The point being argued is that we should
decrease our dependance on it for various reasons including reducing the
bandwidths in the heads of us network/system administrators inside of
Digital.

    I agree with the point that DECnet has lost the war to TCP/IP.  I also
    believe that we should be exploring the use of TCP/IP as our main
    networking technology internally.
    
    But, unless we can do something to make our TCP/IP connections stable
    and reasonable, it's not going to happen.
    
    Even at this hour, our connections to the Web are unusable.  I can't
    even get the Digital homepage to come up reliably.  Everything seems
    out to lunch.
    
    I've supported systems with DECnet for well over a decade.  During that
    time, a ten minute lapse of function would be considered unusual, 
    even across thousands of miles.
    
    Since I've started working with the Web, I've gotten used to the fact
    that it's unusable about 10-20 percent of the time.  I'm not even talking
    about external systems here -- I'm talking about reaching OUR boxes.
    
    Others here have explained what the technical problems are.  Unless we
    fix them, we shouldn't bet our business on such poor connections.
    
    We cut the fat.  Then we cut the meat.  Then we started slicing bone.
    
    Now we've started paying the butcher.
    
    -- Russ

    
     Hey... if we created the cash cow, then we should milk it and then
    butcher it. If someone else butchers it, we loose. Do what the
    customers want... but don't *ever* forget your installed base.
    
    Something I heard in the past...."if we could just get our ALL-IN-1
    accounts to upgrade to TeamLinks, it would be a billion in revenue."
    
    Now take that and apply it to DECnet. Problem is we really cannot
    deliver to all our installed base now can we?
    
    -Mike Z.

Is this true....really?

If this is true what to do about the wholesale abandonment going on
out there?

I'm not suggesting that we stop selling it...I'm suggesting that
we stop depending on it internally...and after that exercize is
complete, we then create a DECnet to IP migration program for our
customers who still run DECnet.

This idea of DECnet applications running over TCP/IP is about as
elegant as SoftWindows 2.0 on Digital UNIX for running MS Word,
IMO.

Now, those of you who don't want to bet our business on TCP/IP...

huh.

OK. I'm learning.  You can lead a horse to water....

-Stephen

re .122

Yes, DECnet is a cash cow for us.  And last time I saw projections, it was
expected to remain that way for at least a few more years.  Management in this
company clearly understands the current and future value of DECnet, as evidenced
by the attitude of "keep it healthy," and by carefully moving the entire product
set into (mostly) maintenance mode.

>This idea of DECnet applications running over TCP/IP is about as
>elegant as SoftWindows 2.0 on Digital UNIX for running MS Word,
>IMO.

Why?  On the one hand you say we need a migration strategy, and on the other
hand belittle part of the effort to provide the platform that will help allow
that strategy to become a reality.  By the way, it's not just Digital that
thinks DECnet apps over IP is an important thing to have - one of our major
competitors in the TCP/IP stack space invested a considerable amount of effort
developing a product with similar functionality.

--Scott

    re .120
    
    good point.. having supported DECnet of both flavors as well as 
    TCP/IP nets over the past several years, it "was" indeed an unusual
    occurance that the (phaseiv) network would be disturbed for greater than 10 
    minutes or so. But I do recall router wars that could destablize 
    a network in a hurry. A problem such as this was infinitely more "fixable"
    than some of the issues one can have with TCP/IP and OSI I might add.
    
    Stale arp cache entries / bad static routes / anybody who decides to
    to supply rip routes etc..DECdns not updating for months at a time,
    DECdns servers not responding at all, magic happening to your phase V
    end system when  a Phase V router suddenly pops up out of the clear
    blue, easy to use network control languages like NCL , no network
    control languages, incorrect resolv.conf files, icmp redirects to black
    holes and so on.... 
    
    give me phaseiv DECnet with extended addressing and a name service that
    works anyday...
    
    :)
     

I was going to check some spec results for a different note, but (once
again) it appears "the outside world" isn't reachable via www (at least
by either of two proxy servers on the east coast.)

><<< Note 4454.108 by HDLITE::SCHAFER "Mark Schafer, Alpha Developer's support" >>>

>    >Digital in 1996 does not have the resources to deliver two...
    
>    John,
    
>    Are you sure you want to go with that argument?  I'm sure that I can
>    think of some other areas where it might be applied.
 
    
    
       
>    Mark

    
    Mark,
    
    Yes I still want to go with that argument... We're talking about 
    different market dynamics...
    
    With regards to our multi-operating system strategy and positioning
    on Alpha: 
    
    Different OSs provide different levels of service, performance, 
    stablity, and added value that (last time I checked) customers
    are actively buying in the marketplace from Digital Equipment.
    
    OpenVMS, WNT, and Digital Unix are used by customers for very different
    types of jobs. There is substantial overlap only in the vein that you can 
    use a Tractor-Trailer rig to commute to work or you can use a Ford Escort.
    
    One will give you plenty of respect on the road, but lousy gas milage,
    the other will get you economically to work but very little room on 
    the highway while you drive...
    
    Digital needs to encourage customers to choose the lowest cost 
    application deployment platform that will do the job for them and
    their companies and recommend the Industrial strengh systems for
    the production systems that need them.  
    
    It's to Digital's benefit that today we can sell Windows, Unix and 
    OpenVMS to meet All the customers needs today.  
    
    This addresses the largest part of the computermarketplace.
    
    
    On the other hand:
    
    DECnet and TCP/IP are used (and expect to be used by most customers)
    as a simple transport mechanism for messaging, file transfer,
    authentication, and transparent task to task communications in 
    Client/Server Apps...  
    
    Given that most customers (in my experiance) have made a direct 
    decision to support TCP/IP in LAN and WAN environments, it becomes
    a simple case of economics:
    
    Does DECnet Phase ? represent any cost savings, or added value (to 
    the customer)?
    
    For my customers the answer has been
    
    "NO! And let's stop revisting this, Tell me what TCP/IP support you
    have..."
    
    Bundling DECnet Phase IV, Phase V with the OSes and claiming that
    it's selling well is a myth.  How many customers are using the 
    product or have real plans to use the product...
    
    Unbundle this product entirely, no prepackaged network software with 
    systems/NAS bundlings and let the customers choose at buy time what 
    NETWORK OPERATING SYSTEM they want to support... The answer would be 
    very clear...IMHO
    
    
    Digital needs to support one network strategy and convey it to
    customers... A commitment to TCP/IP seems the only viable 
    choice in 1996.
    
    If DECnet did something dramatic that TCP/IP applications couldn't do, 
    If customers were demanding applications written to DECnet interfaces..
    If ....
    
    Enough with the IFs... I would rather put up with one migration 
    to TCP/IP v6 then see Digital Suffer the pain migrating to IS to IS 
    routing ... at least we'd be in league with what our customers are
    going to be doing...
    
    Better technology rarely wins in the marketplace unless it's the 
    lowest cost... Adequate technology with the lowest price wins in 
    the long run...
    
    JMHDO (Just My Humble DEC Opinion)
    John W.

  I really didn't want to get into this one, but it isn't going away.

  Sigh.

  I've been at the same customer site for over three years; it gives you a 
very different perspective from the shorter assignments.  Over the three 
years I've watched them blame every technology under the sun (pun intended) 
for the IS problems.  The problems aren't Pathworks, TeamLinks, cc:mail, 
Netware, LAT, VMS, UNIX, DECnet, TCP/IP, DEC, HP, SUN or CISCO.  However, 
they are getting closer to thinking that NT is now the answer to their woes.
Riiiight!  What they absolutely have to fix first is the lack of organization 
and lack of understanding of what their users actually need the computers for
-- something along the lines of "if you don't have a goal defined, you can't 
ever reach it."  And where have we heard THAT before?

  Two years ago this customer planned to scrap all Pathworks, TeamLinks and 
DECnet to go Netware, cc:mail and TCP/IP.  A year ago, they did an about 
face and decided to scrap all Netware and cc:mail and go Pathworks and 
TeamLinks.  The environment is still mixed to this day, although the Netware 
and cc:mail users are now only about 10% of the total.  They've added 
some NT servers and except for some typical startup pains, they're okay.  

  We have very few DECnet problems -- those are mostly duplicate addresses and 
nodenames.  I'm not sure of all the TCP/IP problems but Netmanage on the PCs 
has been a real challenge.  However, TCP/IP is going to replace DECnet and LAT 
wherever possible mostly because they want to standardize (to minimize what 
they need to know to troubleshoot).  They are currently converting the printers 
from LAT to TCP/IP and once they make a "final" decision about Pathworks, 
DECnet will also go.  I will miss it.  I love VMS, DECnet and Macintosh but I 
guess I can grow to love the others as well.  It's a matter of survival -- the
more I know about a variety of systems, the more valuable I become.

				SQ

PS.  Stephen, I think you'll get further with this group if you'll refrain 
from blaming technology, especially technology that works for a lot of us.  
As an example: an IS person out here sent an e-mail message without the 
attachment and then blamed TeamLinks for "deleting" it.  He still hasn't 
lived it down, especially since all the recipients on his large distribution 
list have all forgotten to add attachments at one time or another.

    Will you folks stop with the this is better than that drool. The title
    of this note suggests help with updating the user community on why
    our corporate network has slowed to a crawl in places. I too would like
    to be enlightened on why performance (facts) has turned south.
    
    -Bruce Ferjulian-
                                                              
    

No, I will never cease...I feel like it is my responsibility. In fact,
one of the reasons I was hired close to a year ago now was that my
manager wanted someone with a 'fresh' 'non-old-time-deccie' attitude.
I know I'm coming across as a gadfly...but that is kind of my intention.

And don't get me started on Pathworks...

Again, this stuff effects me directly, I've got to deal with it every 
day.

If DECnet is indeed a Cash Cow for this company, then I need to 
rethink my position on it's future as a product for Digital.  I
don't manage anything (products or people) but my mouth, so it's not 
really that important to the company what I think about it anyway...
but I am a customer in a sense, because I have to manage it an support
it...and I think it kind of sucks...and that's my opinion.

DECnet does not need to be on our wire, IMHO.

Now, all the 'quit whining' 'quit slamming' 'quit flamming' comments
I get in here roll off of me like water on freshly waxed fiberglass,
because I'm not just gonna sit here and quietly accept the BS that
goes on within Digital...

I do hope that my comments in some small way affect the Digital mindshare,
and the day that I start accepting a lot of stuff that is currently going
on in this company is the day I feel that I'm kind of selling out on
myself.

And if I do make a stupid statement and get eaten alive in here...oh well,
I propably deserve it.  I'll learn from it and move on.

-Stephen

I have found it somewhat ironic that I've been (interleaved with several
other tasks) reading this string, including all of Stephen's comments
about how DECNET is unstable and does not work etc. From the same site,
via DECNET across the continent to where HUMANE resides.  Never a hitch.

At the same time, I've been asked to get specs on some Macintosh computers.

Now, I know that Apple has comprehensive info readily available on their
Web servers.  For two days (!!) I haven't been able to make a solid
connection from Seattle to Cupertino via TCP/IP to retrieve info that I
know is there.  The gateway is down one time, the connection times out
the next, the remote server is down another time, etc...

The point is that it is not all black or white.  I haven't seen any
DECNET problems at all, not even on my Digital UNIX OSI end-node.  Stephen has.
Stephen hasn't seen any problems with TCP/IP, but I've had incredible
frustrations getting decent connections.

There are problems for users of either protocol, and you know what?  They are 
really not problems with the protocol, but with the infrastructure.  It's
not up to the task, and it's showing.  But then most of us could have predicted
that years ago when they started slashing bandwidth...

We have a common foe, and that is the mentality that slashing bandwidth
at a time of increasing usage makes sense.

As to whether Digital should continue to sell DECNET, that is a dollars & cents
(NOT SENSE!!) decision.  Any of our feelings will likely not have any impact at
all on that one.

Kevin

    meanwhile, all the bandwidth this discussion is using is generating
    more heat than light, and the people who really can make a difference
    to the situation probably don't read here. The Easynet people *do* read
    JETSAM::EASYNET. But the people who set the budgets probably don't know
    how to use Notes, and they are the ones who hold the key to a fix.
    
    In passing: OSI (the architecture) has already addressed a whole load
    of scalability and multi-vendor problems which most of the TCP/IP world
    haven't even thought about yet. But they will, soon. Hopefully they can
    learn from other experiences.
    
    regards
    john
    
    decnet iv, uucp, decnet-vax extensions, decnet-osi, TCP, LANMAN, etc,
    etc, etc 

    
    re .127 - a couple of years back I participated in an invitational
    conference/working session on the future of network management.
    After a few days of widely ranging discussion, the group came to
    the essentially unanimous conclusion that the most serious impediments
    to successfully managing large mission critical networks were mostly
    sociopolitical in nature.
    
    len.
     

	First for the corporate name space...

		What happened was that a software bug caused a number
	of name servers to go down at once and bringing them back up
	even once the problem was identified was difficult.  This problem
	was identified and as far as I can see, is solved.  The
	problem had nothing in the least to do with OSI so I don't know
	how that came in to the discussion.  (PhaseV maybe, but not OSI...)
		Name space is a single source point of failure... very 
	visible.  Somehow Chaos is better distributed on DECdns than
	DNS/Bind.

	TCP/IP vs. DECnet as a corporate strategy...

		You mustn't be reading much marketing literature.  Internet
	ready VMS and your TCP/IP company?  Digital is a leader in the 
	IPv6 community with prototypes on Digital Unix and OpenVMS.
	Suggesting we rip DECnet out of our product set is ludicrous.  Tell
	someone, sorry you must migrate to TCP/IP in the next two years
	would be insane.  Now that customer force to replace all their
	routers (perhaps) and applications has a whole new set of choices
	that might not include Digital.  DECnet is there to allow people
	to maintain current applications and networks ...  There are also
	important niche markets that we sell OSI apps to to that have some
	hefty customers that have invested alot in some of the DECnet/OSI 
	technology.

		Clearly, all the operating systems are focusing on IP for
	the future.  Where's the problem other than there was a bug that
	should have not have gotten where it got?

	-Pete

    OK, I give up for now.
    
    This issue will come back up in a few years.
    
    When an end user at my sight starts telling me the state of
    the network I manage...it's time for me to take a break...
    
    One thing is for sure...DECnet will die here...as soon as it is
    feasible, let me rephrase that...DECnet/OSI will die.
    
    And by the way...the DECdns server this site depends on is still
    down....going on day 14 or so.
    
    -Stephen
    
    (posted from an NVAX running DECnet phase IV)

    All this sounds like the 100Mb Ethernet holy wars, which were proceeded
    by the UTP vs. 10BaseT Ethernet wars, which were proceeded by the
    Token/Ring vs. Ethernet wars ...
    
    My simple view - OSI has not been the 100% success projected, but the
    problems with current TCP/IP will force a change sooner or later.  What
    about a migration strategy for both groups to a COMMON revised IP(tng)?
    (Kind of like how both IBM's MicroChannel and the EISA bus standards 
    have been superceded by the common PCI standard, and we are all the
    better for it.)
    
    just my 2bits ... Charles

>2. DECnet Phase V problems/bugs, IS to IS routing

	Stephan,
		What makes you say this?  Has your site migrated
	from distance vector routing to IS-IS?  I thought
	your problem was DECdns servers at your site.  (This isn't
	part of the discussion so much as a curiousity in that
	I didn't realize that IS-IS OSI routing was part of the
	problem much we are seeing.)

		I think this is a fair amount of consensus here;
	We use the network heavily and it impacts us when something
	is broken.  Digitals cutbacks in network infastructure support
	has affected our ability to work, (or at least whine in notes
	files).  Digital needs to integrate it's 3 operating systems
	(OpenVMS legacy, Unix possibly the next Legacy, and NT aka give
	all your money to BillG), very well with the IP network, (IPv6).

	

re .129 (sorry for the rathole -- one last note on the subject)

>No, I will never cease...I feel like it is my responsibility. In fact,
>one of the reasons I was hired close to a year ago now was that my
>manager wanted someone with a 'fresh' 'non-old-time-deccie' attitude.
>I know I'm coming across as a gadfly...but that is kind of my intention.

Hmmmm, a fresh approach to solving a problem would be good; a gadfly, we 
don't need.  Are you just trying to get a rise out of people?

>And don't get me started on Pathworks...
.
.
.
>If DECnet is indeed a Cash Cow for this company, then I need to 
>rethink my position on it's future as a product for Digital.  I
>don't manage anything (products or people) but my mouth, so it's not 
>really that important to the company what I think about it anyway...
>but I am a customer in a sense, because I have to manage it an support
>it...and I think it kind of sucks...and that's my opinion.
>
>DECnet does not need to be on our wire, IMHO.

It's been my experience in consulting that we make a lot more progress 
toward fixing a customer's problems when everyone stops slamming the products
and looks for real solutions.  Define the problem, examine solutions, make 
a decision, assign the work, evaluate the changes and do over.  I repeat, 
for the most part, it ain't the technology that's to blame.  BTW, I'm 
glad you aren't at a customer site slamming some of our best products.

				SQ

    Gosh it makes me real sad to see the heated and off-base statements 
    in here such as "DECnet will die".
    
    You know, when ISO developed the famous 7-layer reference model they
    neglected to tell us that a future release of the model would address 
    the missing 3 layers.  
    
    The Easynet (i.e. the multi-protocol DECnet, IP, SNA, Appletalk, Video 
    and Voice network) problems are due to primarily to Digital's 
    implementation mistakes with level 8 of the model and also a certain 
    amount of confusion with level 9.
    
    Furthermore, a lot of the discussion in this thread has degenerated
    to irrelevant issues at level 10.
    
    	THE ISO 7-LAYER REFERENCE MODEL
		    
    	1	Physical
    	2	Link
    	3	Transport
    	4	Routing
    	5	Session
    	6	Presentation
    	7	Application
    
	ADDENDUM
    	8	Finance
    	9	Politics
    	10	Religion
    
    
    /Chris.    

Never ceases to amaze me that when someone in this company questions
the status quo...how popular it is to do what your doing in your note.

I recently finished some consulting at a customer site as a matter of
fact...a site where the Network group was killing both DECnet and 
Pathworks...a good part of my time was spent helping one of the
system managers understand why his company was giving him a top
down initiative to blow away this technology.  His position was
the same...'it's not the tecbnology'.

There is where you are categorically wrong.  That is
exactly what is going on out there. Every concienscous IS manager
is questioning every last ounce of technology he/she owns.  Why?

Because it's simply too difficult to manage twenty different pieces
of whiz band 'information services that protect your investment' hybrid
glue this to that solutions.  In fact, in our case, it's just like way
too difficult to even do business with us at all (Digital)!!

And I submit to you that it's DECnet in a way...it's part of our problem.
I spend hours and hours with end-users helping them figure out how
to extract powerpoint slides from VMS mail so they can print them out
in time for a customer presentation....days and days searching for
firmware and pointers to kits in notes files on servers so old it takes
3 minutes to move from reply to reply...20 minutes to do keyword searches.
Find this part number or that part number....oh!! I can't use an external
part number?  Do you know the internal equivilant?  No? Go look it up
in VTX?

I can go on and on...from corrupt subsets on consilidated distribution
to brand new networking equipment with 2 year old firmware.

Try managing all of this technology for a while...it's so easy for you
to give me the 'it's not technology' speech when you don't have to
make all of the 'it's not the technology' pieces work!!  And I mean,
day in, day out, in a production environment....not install and throw
over the wall.

Pathworks and DECnet cause this site extreme pain...and I mean extreme.
Nothing would please us more than to just rip all of it out...I'm
not the only one who feels that way...

So, am I just screaming to here the sound of my voice?  Am I just trying to
get a 'rise' out of people?  The answer is no.  I'm telling you exactly
what our customers say about us.  I'm giving you a dose of reality.
We piss our customers off...unless you become a died in the wool DEC shop,
it's almost impossible to do business with Digital.  

We need to streamline everything that we do...part numbers, protocols on the
network, mail systems we support, etc. etc.  Until we do that, our recovery
is not yet complete.  We are not there yet.

And the first step to doing that is to align ourselves with what our 
partners/peers and yes even our competitors are doing to do that...that is, 
take a long hard look at enabling technology and weed out the stuff that causes 
more harm then good.

I'm sitting here now realizing that this is impossible...and for the first 
time since I've been here I'm seeing why whole departments are divorcing 
themselves from relying on corporate infrastructre, why I'm setting up three 
T1's even as we speak...why we are considering paying an ISP for
our internet access.....aaaaaaarrrrrrrgggghhhhhhh!!!!!!!!!!

This is sillyness!!  WE NEED TO WAKE UP!!!!!!!!!!

Maybe I'm wasting my time here...but you know what?  I'm doing this because
I believe in Digital...and I know that we can change this if we really want to.
And this is really all that I can do from this vantage point.  It would be so
easy to just say...BLEEP it!  And just get my T1's setup up and blow DECnet
of of the LAN and ignore the rest of the company!!  God help us if that's
what becomes of us!

But the first step is to listen to our customers...not the died in the wool
loyal DEC shops....but the ones who don't have a single piece of our hardware.

Anyway...shoot the messenger it you must...

I gotta get back to chasing down some firmware.

-Stephen

    Well Mr "Fresh-out-look" White.
    
    Can you tell me why I haven't been able to copy files over your
    precious little \\NTNONE share for three days???
    
    

    If I had a $1 for each time NFS timed-out or dropped data here in
    ZKO2-3, I'd afford that BMW by now...
    
    We can argue protocols all we like...  Each has pros and cons (I
    personally think that IP has a few more pros than OSI), but none
    of them are perfect.  Neither "side" has the market on management
    tools either, some suck, some are great.
    
    				-John

>Try managing all of this technology for a while...it's so easy for you
>to give me the 'it's not technology' speech when you don't have to
>make all of the 'it's not the technology' pieces work!!  And I mean,
>day in, day out, in a production environment....not install and throw
>over the wall.

I thought I made it clear that I've been out here at the customer site for 
over three years -- that's 40 hours a week * 45 weeks (give or take for 
vacation and training) * 3+ years.  I think that qualifies as day in, day 
out management in a production environment, at least the customer thinks so.

>Pathworks and DECnet cause this site extreme pain...and I mean extreme.
>Nothing would please us more than to just rip all of it out...I'm
>not the only one who feels that way...

Pathworks and DECnet aren't the answer for all sites; it IS partially the 
answer for my customer.  I've supported these products successfully for years 
and find your comments way over the edge.  I hate the technology wars and 
find them counter productive.  If your customers have problems, you help them 
find solutions; it's our job.  Is it always easy?  No.  Do we have internal 
problems?  Yes, and I'd like to see them fixed.  I'd also like the vendors
I have to work with to fix their internal problems and the customer and ....
This is the day to day reality and it's my job.  Someone who works for DEC 
and dumps on our products just makes it that much harder for the rest of us.

				SQ

    re -.1
    
    Gottcha beat...10 plus... and I work on some stuff that ain't made
    by digital these days. And guess what... there is more than one of us
    down here. Digits, that is. The customer is moving where the industry
    goes...some of our stuff comes along..some doesn't.
    
    We got the message a long time ago.
    
    It's the solution...not the product. 
            
    -Mike Z.

Send mail to DECWET::CAREY (carey@zso.dec.com)

I don't manage that system.

thanks,

-Stephen

(it's Friday...just spent all week trying to get a DEChub 900
upgraded to the latest firmware...finally got it...but did
not fix the problem....I'm gonna go try to beat the sh*t out
of a little white ball....*poof*)

DECWET is a cluster with more than a few users... DECWET::WHITE is one person's
address.  Referring to one is not referring to the other, please keep it clear.

I'm sure more than a few people here prefer support for arguments over general
assertions (for any topic of discussion).  I see enough bad arguments on usenet,
I don't need to see them here as well.

-Amy

RE: .139

>I spend hours and hours with end-users helping them figure out how
>to extract powerpoint slides from VMS mail so they can print them out
>in time for a customer presentation....days and days searching for
>firmware and pointers to kits in notes files on servers so old it takes
>3 minutes to move from reply to reply...20 minutes to do keyword searches.
>Find this part number or that part number....oh!! I can't use an external
>part number?  Do you know the internal equivilant?  No? Go look it up
>in VTX?
>
>I can go on and on...from corrupt subsets on consilidated distribution
>to brand new networking equipment with 2 year old firmware.

Stephen, thanks for explaining it so well.  VMSmail doesn't directly handle
foreign types of files, servers are old and overloaded, we can't find part
numbers and when we can they are the wrong type, and so we need to use VTX,
there are corrupted kits on our media and the network equipment is out of rev.

And the solution is obvious: dump DECnet and all of these problems go away.

If we dump DECnet and only use IP, then VMSmail will automatically invoke
the PowerPoint Viewer, all servers will instantly become updated and much
faster, our internal systems will automatically handle all types of part
numbers and we won't have to use VTX, all of the bits on all of our kits
(even the ones out in the customer's hands) will automatically be corrected,
and all of our networking equipment will magically be up to rev.

Now I understand!  It is so simple once you explain it clearly...

$ SET MODE/NOSARCASM  -or-  % setenv DISCUSSION serious

I hold the opposite opinion than you do: I prefer DECnet to IP.  But at least
I am honest enough with myself to realize that this is based solely on my
experience and background: I have used DECnet much more than I have used IP,
and have therefore studied it much more than I have IP, and am therefore more
comfortable with DECnet than I am with IP, because I am able to do more with
DECnet than I can with IP.  But again, I realize that this is strictly due
to my level of knowledge about both.  If I studied IP to the same level, I
would certainly realize it's strengths and weaknesses, the same way I realize
the strengths and weaknesses of DECnet.  And I would certainly become as
capable of managing IP as I am capable of managing DECnet.  And I will make
the same statement about OSI and NetWare and AppleTalk and (your favorite
networking protocol here): if I spend the effort to learn it I will be able
to use it effectively, and if I don't then I will have a distorted and very
limited view of it's capabilities, such that I won't be able to use or manage
it effectively.

"Never judge a person until you have walked a mile in their shoes".  This is
an aphorism with a grain of truth in it: until you are as capable of managing
DECnet as you are with IP, don't make unfounded and ill-considered statements
about it's capabilities.

I see a lot of the same customers mentioned by others in this string (John
Fransden and others).  And I see the same trends mentioned by those people,
that DECnet is for legacy applications and IP is for all new stuff.  But
this does not equate to OpenVMS being legacy: many of my customers choose
OpenVMS for new applications for a variety of reasons, primarly because it
does some things much better than any other system available.  But they
choose Digital UNIX and Windows NT and Windows 95 and HP/UX and MVS and ...
for the same reasons: each of them does some things much better than any
other system available.  But every one of those operating systems has IP
implemented on it, and this is what my customers are choosing almost 
exclusively: no matter what the operating system, the network protocol is
IP.  DECnet and NetWare and AppleTalk is for compatibility with existing
systems, and will not be used for anything new, and *no one* is using OSI.

Now, do I believe that Digital should do everything possible to move into an
IP world?  Absolutely, because this is the world our customers live in, and
we must live there too.  Do I believe that every one of our systems should
speak IP?  No, because there is no business reason to change what works.  Now,
all *new* systems should use IP, and should consider using DECnet if there is
business justification to do so (and having it bundled with the O/S is not a
good enough business reason to do so).  But they should consider DECnet the
same way they consider NetWare or AppleTalk or OSI: do they require frequent
communications with systems that only speak those protocols?  If yes then
install them, if no then don't.  This avoids all religion and politics, and
makes the decision in the same way our customers do: for business reasons.

-- Ken Moreau
   DECnet bigot who would never *dream* of trashing other protocols

re: .146

>And I see the same trends mentioned by those people,
>that DECnet is for legacy applications and IP is for all new stuff.  But
>this does not equate to OpenVMS being legacy: many of my customers choose
>OpenVMS for new applications for a variety of reasons, primarly because it
>does some things much better than any other system available.

The market situation and the situation within Digital are two
different things.  Obviously we shouldn't kill either DECnet
or VMS if we're making a profit off of them.  But within the
Digital world, the business unit IS managers have all been
saying that SAP/R3 on Digital UNIX is the centerpiece of all
future application work (they've been saying this for a couple
of years, though i don't know if we're close to a worldwide
implementation yet).  And, more recently, they've been saying
that NT is the desktop strategy.  The logical consequence of
this SHOULD HAVE been to freeze application development on
VMS and leave the VMS/DECnet infrastructure at the rev it was
on about a year ago.  I forget what that rev was, maybe V6.1,
but whatever it was it supported DECnet Phase IV.  But we
acted like we expected to keep upgrading VMS systems ad
infinitum, "so we can stay supported", which made going to
DECnet Phase V also a necessity, since Phase IV support was
being dropped in later releases of VMS.  To go to DECnet
Phase V required an investment of dollars in operational
training and has cascading expenses for the telecommunications
side of the house.  But is it of any benefit to the UNIX/NT
strategy to go to DECnet Phase V and causing these cascading
expenses and side-effects throughout the infrastructure?

If someone can answer that question "Yes" and explain it,
then i'll accept that maybe we made a good investment.  If
freezing VMS at V6.1 and DECnet at Phase IV would have been
just as good a solution from the standpoint of future UNIX
and NT applications, with the money spent on upgrading our
expertise and capabilities on the IP side, then we made a
bad investment.  But i suspect that (whatever the answer)
the cost-benefit wisdom of what was done will remain mostly
hidden from the movers and shakers in this company.  Alas.

- paul

Here are some good reasons to go an all IP network...

	All of our customers are moving to IP

	All of our competitors are moving to IP

	Nobody will be investing in DECnet, IPX, Appletalk, 
	or Banyan in the future

This is not to say that DECnet is causing our current problems, but
rather a poorly managed network infrastructure.  However, if we concentrate
on what the future holds, we as a company will become much more experienced
and valuable to our customers.

If you don't believe this, you aren't very close to the market.

Brad.

re .148,

> All of our customers are moving to IP
> All of our competitors are moving to IP
> Nobody will be investing in DECnet, IPX, Appletalk, or Banyan in the future

I have heard for years how "everybody" will be running this operating system or
that application or this network protocol or that user interface.

It has never happened.

I talk to customers every day.  They run a variety of network protocols and
operating systems and always will.  Some things are more popular than others,
but thinking that ONE THING will solve all your problems is the reason Ken Olsen
made his often-misinterpreted "snake oil" comment.

Saying "all" our customers or competitors will be doing something or "nobody"
will be doing this or that is an exaggeration.

One size does not fit all.

Paul

> I have heard for years how "everybody" will be running this operating system or
> that application or this network protocol or that user interface.

> It has never happened.

Since the late 80s people have been saying that Wintel (Windows/Intel)
will win the desktop. IT HAS! Does that mean nobody today runs Apple
Macs, UNIX workstations, or (gasp!) 3270 or VT terminals on their
desks; absolutely not!  However, any corporation that is not making
Wintel a major part of its desktop strategy must have some significant
jusstification to do so.

The dominance of IP in the protocol space is no less than the dominance of
Wintel in the desktop space.  It has been forecast; it is happening; at most
of my customer accounts, it has already happened!

> I talk to customers every day.  They run a variety of network protocols and
operating systems and always will.

If the dominant protocol in your customer base is not IP, then you are
obviously focussed on a niche.

Ram

> If the dominant protocol in your customer base is not IP, then you are
> obviously focussed on a niche.

I didn't say TCP/IP was not dominant.  Customers with whom I deal run TCP/IP,
NetBEUI, DECnet, IPX, AppleTalk and LAT.  Each protocol has advantages and
disadvantages, and different reasons for existing on someone's network.

Paul

RE: .148

>Here are some good reasons to go an all IP network...
>
>	All of our customers are moving to IP
>
>	All of our competitors are moving to IP
>
>	Nobody will be investing in DECnet, IPX, Appletalk, 
>	or Banyan in the future

I totally disagree.  You have eloquently stated why Digital must have an IP
strategy, and why we must offer a world-class IP product on every system we
offer, and why we must train our people to be able to offer world-class
support on IP.  All of these things are true.

None of them has anything to do with whether we must go to an only IP network.

Must we run IP internally?        Absolutely.  
Must we run *only* IP internally? Absolutely not.

>If you don't believe this, you aren't very close to the market.

I believe that I am "very close to the market", in that I work practically 
exclusively with customers and Sales Reps (from both Digital and our partners).
My only connection with the internal network is as a user.  And therefore I
can approach the problem with a degree of detachment, and state that I don't
care if we use DECnet, IP, NetBEUI, AppleTalk, NetWare, or two cans and a long
piece of string (and with the current performance of the network, that last
is sounding more and more likely).  All I want is a reliable network that 
allows me to access the systems I need whenever I need them.

And you know what?  This is how my customers state the problem to me when we
are working together to revamp their current networks and design new ones.
And you know the first thing I tell them?  "If it ain't broke, don't fix it".
If you have a piece of network that works, for heavens sake DON'T TOUCH IT!  
Design and implement new stuff, replace old broken stuff, but don't change
what is delivering functionality you need just for the sake of purity, or
because some network person has an irrational bias for or against one or
another protocol, or just to be able to say "The only thing running on our
network is ...".

Because I can tell you truly, that doesn't sell to the Board of Directors.
The only thing they care about is, 1) Does the network deliver what the 
customers need and 2) how much did it cost to buy and 3) how much does it
cost to maintain?  If there is some crufty old piece of SNA gear out there
doing the job, costing nothing to buy and very little to maintain, then their
attitude (and mine) is *LEAVE IT ALONE* and spend the money somewhere else
that you get a good return-on-investment.

To switch from our current mish-mash of protocols to an exclusively IP network
would cost millions of dollars, would throw our current systems into chaos,
and would offer zero/none/nada/zip/bupkus business benefit to Digital.  And
if you have evidence to the contrary, I am sure that the SLT would be very
interested to hear it.  But I can tell you, from dealing with many customer
SLTs, that the cost of conversion better be much less than the business benefit
in real, hard dollars, and there better not be any "xxx is better than yyy
from a technical standpoint", because that doesn't matter *AT ALL* to SLTs
or end-users.  They only care about service delivery and costs.

-- Ken Moreau

What difference does all this religious bickering over DECnet vs. IP do? Here we are weeks 
into this mess and the net is still unreliable. I still have to go to MS Net to get a 
reliable Internet connection. This is pathetic for a company that proclaims itself to have a 
networking core competence. If customers get wind of how screwed up our own network has 
become, we can kiss their network consulting business goodbye. It's time to buy the cobbler's 
kids a pair of shoes, for Pete's sake.

-OFWAMI-

  <<< Note 4454.153 by NQOS01::nqsrv348.nqo.dec.com::Werner "NORMAN WERNER" >>>
               -< The mess persists and the arguements go on... >-

    What difference does all this religious bickering over DECnet vs. IP
    do? Here we are weeks  into this mess and the net is still unreliable.
    I still have to go to MS Net to get a  reliable Internet connection.
    This is pathetic for a company that proclaims itself to have a 
    networking core competence. If customers get wind of how screwed up our
    own network has  become, we can kiss their network consulting business
    goodbye. It's time to buy the cobbler's  kids a pair of shoes, for
    Pete's sake.

    -OFWAMI-

    

re.147:

> since Phase IV support was
>being dropped in later releases of VMS.  

Any idea which release?

Dave.

The is due to be the "Gryphon" release which I believe will
be called OpenVMS V7.1.

However, they have tried to enforce this before and then backed off due
to customer pressure. 

M

  Do you suppose *WE'RE* a big enough customer that they would
  listen to *US*? Or are we perceived as a "captive" account
  that will accept the "upgrade" no matter what?

                                   Atlant

re: .155

>> since Phase IV support was
>>being dropped in later releases of VMS.  
>
>Any idea which release?
>
>Dave.


I believe that OpenVMS V7.1 will no longer have the Phase IV code base
available: Phase V is backwards compatible with Phase IV so it's wrong to say
that support gets dropped - you just use NCL or NET$MGMT instead of NCP. 

You can avoid all the namespace hassle if you use a local namespace and Pete
Carson's DCL procedure to turn ANCHOR's Phase IV database into something
suitable for Phase V's local name space. 

Antonio

re Note 4454.158 by MARVIN::CARLINI:

> I believe that OpenVMS V7.1 will no longer have the Phase IV code base
> available: Phase V is backwards compatible with Phase IV so it's wrong to say
> that support gets dropped - you just use NCL or NET$MGMT instead of NCP. 
> 
> You can avoid all the namespace hassle if you use a local namespace and Pete
> Carson's DCL procedure to turn ANCHOR's Phase IV database into something
> suitable for Phase V's local name space. 
  
        Even if the new networking software is equal or better in
        quality than Phase IV, what you mention above does require
        retraining and increases the opportunity for operator error
        both in the transition and until the operators become as
        familiar with the new as they were with the old (neglecting
        differences in the usability of the software).

        Bob

  
        Even if the new networking software is equal or better in
        quality than Phase IV, what you mention above does require
        retraining and increases the opportunity for operator error
        both in the transition and until the operators become as
        familiar with the new as they were with the old (neglecting
        differences in the usability of the software).

        Bob

Right on Bob!  Having been forced to migrate off Phase 1V when I upgraded
from ULTRIX to Digital UNIX, 3 years ago, I bear testimony to the difficulty
in administrating Phase V (in the the absence of training).  From my
customers' perspective, this has simply hastened their flight to IP!

re: .157

>  Do you suppose *WE'RE* a big enough customer that they would
>  listen to *US*? Or are we perceived as a "captive" account
>  that will accept the "upgrade" no matter what?

I would imagine so if *we* get organized enough to present a case to
them. That would probably take a significant number of organizations
to complain though.

The trouble is *we* have been 'voting with our feet' and switching over
to TCP/IP so there probably isn't enough pressure in the system. Somebody
from Easynet published a node count and, if memory serves, IP addresses
outnumber Phase V addresses by about 18 to 1. 

Re: Phase 5 includes Phase 4

At the architectural level it does but at the product level it's not so clear.
In addition to the training costs, some OpenVMS software written for DECnet VAX
will not install on DECnet/OSI. I believe it would be  in 'End System Networks'
interest to avoid having their customers face a choice of investing in IP or
in Phase 5. [imho]

M

Re: .161

Nonsense.  "We", as in Digital as a whole, relies more on DECnet than on TCP.
If DECnet were broken in the company, there would be instant complaints.
It's the name servers used by DECnet/OSI that seem to be the trouble spot
for us - luckily most of the company is still running phase IV.

TCP/IP breaks when anyone so much as sneezes - and it's often nearly
impossible to find out what the problem is and how to fix it. 

					Steve

re 149:

	The reality I see at the desktop is plain, be it MACs or PCs.  Running
multiple stacks (ipx and ip) are a major pain in the butt to support.  It is
much simpler to support one protocol.  NT and W95 both come with native IP
support, so not only is it easier to manage, it is cheaper!  How long will
it take customers to see that they can have everybody running the same 
protocol that works with the Internet, comes preinstalled with the dominate
desktop platforms, and is 'free'?  My experience with all types of customers
hooking up to the Internet is virtually 100%.  In fact, customers with fully
functional DECnet networks, that like DEC and VMS, are planning to pull the 
plug on DECnet.  Anything that makes support groups jobs easier and is cheaper,
doesn't take long to sell.  Plus, Internet access is bubbling up from the bottom
of the organization as fast as it is being pushed from above.

re 152:

	Why would going to an all IP Digital network cost any more money than
we are spending now troubleshooting this mess?  I would assume that most of the
routers and host systems already support IP, it is just a matter of configuring
the leftovers...

I am not bashing DECnet, I am very comfortable with it, I am just offering
another view of how to manage our network.

Re Steve's 4454.162: "TCP/IP breaks when anyone so much as sneezes" ...
I'd add "when not competently managed".

I've just returned from a week's consulting at a giant bank -- well, you
make up your own mind whether global operation, 30,000 desktop systems, and
hundreds of servers worldwide qualifies as "giant" -- whose entire network
operation is based on TCP/IP.  I talked extensively with their manager of
network performance, and saw the network management group's latest charts
of how well their network is staying up and performing; the charts are
posted on a bulletin board at the entrance to the network group's offices.

Their network is definitely sneeze-immune.  They manage it well, because
it's crucial to their business.

Draw your own conclusions.

___Pete

re: .162

I did do a selective quote from the note I saw, but we have
about 80,000 IP addresses in use compared to less than 5,000 Phase 5.
I'd call that a significant trend to IP?

I now generally use telnet to bypass connectivity problems due to "hidden
nodes". A lot of my mail now comes over IP and more and more notes are
posted by Gateways. What the numeric inbalance of 80k to 5k does not show
is how much those nodes are used. I suppose that would need some traffic
analysis - alas I've never seen any information there.

M

    This morning, and right now, IP is dead from Brussels. Again.
    
    Laurie.

re.156:

>However, they have tried to enforce this before and then backed off due
>to customer pressure. 

Most customers around here (UK) think we did enforce it, that's why they have 
stayed on VMS V5.5-2.

Dave.

re: .167

> Most customers around here (UK) think we did enforce it, that's why they have 
> stayed on VMS V5.5-2.

For most customers around here (UK) we really did enforce it!

One of the significant differences between the UK and US markets is the number
of customers who use X.25 protocols.  The DECnet Phase IV product for OpenVMS 
V6 does not provide any X.25 support, so its DECnet/OSI or lose your X.25 -

Or of course the choice made by large numbers of customers - remain at V5.5-2

SR

>One of the significant differences between the UK and US markets is the number
>of customers who use X.25 protocols.  The DECnet Phase IV product for OpenVMS 
>V6 does not provide any X.25 support, so its DECnet/OSI or lose your X.25 -

That has caught me out a few times. On OpenVMS AXP V6.1 you can keep Phase IV
DECnet. I also believe that you can have X.25, since on AXP it was 
engineered separately from DECnet/OSI. 

M

>It's the name servers used by DECnet/OSI that seem to be the trouble spot
>for us - luckily most of the company is still running phase IV.

	Steve, it's the name servers OPTIONALLY used by DECnet/OSI...
	DECnet/OSI allows you to use a local database similiar to the
	the PhaseIV database.  These people were unaffected by the
	name space meltdown.  It's only that people want to use 
	distributed name space that DECnet/OSI supports because
	keeping a local database up to date is a pain.  Just as the
	internet migrated from HOSTS. to DNS/Bind.  I'd like to think
	that something we could do will change so that the easynet will
	support the DNS/Bind namespace AND the DECdns name space properly
	but let's face it; that's an unrealistic expectation.

	Customers are moving to TCP and Unix or NT and we need to have
	products to sell in to these markets.  To do this we need 
	to 'milk the cash cows'.  The features of DECnet/OSI
	'darn the name' over the last two years have been targetted at 
	giving people the option of using their existing applications and 
	networks by focussing on things like Local File "PhaseIV style"
	and DECnet over TCP/IP with simplification of installation 
	and configuration.  We don't have the funds to maintain both
	the DECnet 'classic' and DECnet/OSI code base with dwindling
	resources.  Either decision will alienate a large number
	of important customers.  Although it's a big hammer, DECnet/OSI 
	does have the functionality to support both camps.  The feedback
	from customers and internal folks that come to DECUS OpenVMS
	campground and see an upgrade happen in 9 minutes on an Alpha and 
	get to see the Graphical Network Management interface is that
	we did the correct things.  Some indicate that it is too little
	too late.  Most people don't have the opportunity or desire
	to see this demo.

	Unfortunately, customer/internal perceptions are based on real data 
	from 5 years ago that you must set up a DECdns name space, (no fun
	indeed) and answering obscure questions about IDPs and such that
	no customer wants to take the time to learn or understand as they
	know the technology that is important for them to learn is TCP/IP.

	-Pete

	
	

Silly me - here I thought that the single largest advantage of Phase V was
the distributed name service and the freedom from having to keep a local
node database.

Now I know that the problem isn't DECnet/OSI but Digital's brain-damaged
approach to supporting its internal network.  But it's frustrating nonetheless.

I am, by the way, about to try installing DECnet/OSI on one of my systems to
see what it's like.  I carefully read the installation manual and realized
that I needed answers from our local network administrators as to what the
fullnames, etc. should be.  No answer in almost a week.  Sigh.

					Steve

Steve,

If your DECnet Phase IV name is QUARK, your DECnet/OSI fullname is

	DEC:.zko.quark

Note that DECnet/OSI allows for a flat namespace with no areas required, but the
Digital networks people decided to use a facility code-based naming scheme.

Paul

>If your DECnet Phase IV name is QUARK, your DECnet/OSI fullname is
>
>	DEC:.zko.quark

That's the one in the namespace so it must be right. You also need your Phase IV
address and synonym name (QUARK). That's about it. If you don't have a DNS
nameserver on your LAN you'll also need the address (either aa.nnnn Phase IV
style or NSAP-style) of the DNS nameserver you wish to use. And you need to know
your timezone. I think that's about it - defaults are OK for the rest.

Antonio

Re: .169

>>One of the significant differences between the UK and US markets is the number
>>of customers who use X.25 protocols.  The DECnet Phase IV product for OpenVMS 
>>V6 does not provide any X.25 support, so its DECnet/OSI or lose your X.25 -
>
>That has caught me out a few times. On OpenVMS AXP V6.1 you can keep Phase IV
>DECnet. I also believe that you can have X.25, since on AXP it was 
>engineered separately from DECnet/OSI. 

PSI & WANDD on VAX could have been ported to run on VMS V6 under Phase IV.
Product management decided (probably quite rightly) not to divert resources from
Phase V development to do this, particularly since at the time Phase IV code was
due to vanish RSN. I don't know why things were done differently on Alpha VMS.

Antonio

    Just so people don't panic - I'm NOT using QUARK as a guinea pig, but
    rather a hidden node used for nothing other than testing.  If all goes
    well, I may try it on QUARK.
    
    				Steve

Does the corp namespace support hidden nodes?

	Steve,

		The DEC namespace most definitely does NOT support
	hidden areas, (actually DECnet engineering never has supported
	hidden areas officially Phase anything.)

		You can either; - Use Local
				- Not use your hidden area address but
				use an extended address.  This assumes
				zko has an extended address configured
				on the routers.  Ask Mollie.

		By the way, what will happen if you do configure
	your node in the dec name space is that you will attempt to
	connect to a node off lan and that connection will get to a
	name server and not be able to get back to you.  The name
	server will have to time out this connection.  Digital's name
	servers typically have a bunch of these bogus connections
	taking up resources.

	-Pete

Mollie who?

I had a feeling it wouldn't be as easy as everyone made it sound...

				Steve

This part of the discussion isn't relevant to the DIGITAL conference, so I'll
take it offline.

				Steve

    Re: .175
    
    >Installing X.25 WITHOUT DecNet OSI does not make sense, since that
    >way you need to maintain two different styles , i.e. NCP and the
    >old familiar stuff for Decnet and NCL and the new style for the
    >X.25 part.
    
    The PSI V4.3A/WANDD V1.2A code could have been ported as is i.e.
    Phase IV interface and all. No NCL anywhere in sight (I guess you were
    thinking of porting DECnet-VAX Extensions). (I'm pretty glad they 
    weren't ... the Phase V debug tools are much, much better).
    
    >Since the actual Decnet part is 'semitrivial' you are gaining nothing
    >but just maintaining 2 different management styles for ?religious?
    >reasons....
    
    Actually you lose: certainly for PSI & WANDD (and probably for DECnet
    too) NCL gives you much more information and troubleshooting is much
    easier. I would guess that the learning curve is smoother too. I
    presume that most people's problem comes from the fact that they
    already know NCP and any change is perceived as bad.
    
    Antonio
    

.183, a memo posted without header and without obvious permission of the
memo author (violations of P&P 6.54), hidden pending resolution of violations.

				Steve

The memo is in the JETSAM::EASYNET conference.

Yes - so that makes it NOT a violation?  The policy is quite clear, and
we (the DIGITAL mods) have gotten grief before when people posted memos
without permission.  I'm not a mod of EASYNET.  Bob will be reposting the
memo with the required header and statement of permission (or the original
author will do so.)

				Steve

                       ***  EASYnet Capacity Upgrade Approved  ***

folks,


After a year of no upgrades to the network we have received approval to upgrade 
poor performing circuits across the Americas and European Backbones.  I have 
also indicated to senior management that this situation will reoccur next
quarter as we continue to see increased utilization.  We are actively working 
to get the Americas upgrades completed before mid-May.  The European upgrades
will occur early Q1.

I apologize for not responding to any of the previous notes, but without 
something to say and no money we would just be arguing about something we 
could not solve.  There have been recent failures across the network that now
have the attention of Dick Fishburn.  We plan to continue the awareness.

You can expect continued "less than needed" performance as we still see the 
stock price at levels which do not show Digital in favor with the analysys.  
Senior management does not corrolate an increase to network performance to an 
eventual increase to the stock price, although you may disagree.  I suggest 
that if you believe otherwise your messages should to directly to the CIO 
within your business unit as well as your regional data network manager.  This
is not saying that the notesfile is ineffective, but you will receive more
satisfaction if you deal directly with the people who control the dollars.

regards,

Al Doucet
Data Network Business Manager
276-9042