Conference bulova::decw_jan-89_to_nov-90

    
    If you *really* want to see it get into the field, you are going to
    have to apply pressure.  There are more than a few people who think
    tcp/ip for VMS decwindows is a 'fringe' product and who would rather
    not be bothered by this "furrin' crap."  (Not a direct quote.)  If you
    have potential customers, let product management know about them.
    
    					monty

    
    	We have an opportunity for 100+ workstations that is dependent
    on DECwindows support of TCP/IP!!  And this is a primarily VAX/VMS
    oriented customer that has to use TCP/IP to talk with certain critical
    systems like a Cray.  Who are the right people to apply pressure
    on?

    
    In the old notesfile in the tcp/ip note, someone posted a problem with
    Ultrix-to-VMS interoperability.  They had an xliddy log which looked
    like they were reading comp.unix.wizards with rn through an xterm
    displaying on a VMS system.  We need to recreate the condition here so
    that we can use a LANalyzer and I've lost all pointers to your idetity. 
    Would you please contact me?
    
    						monty

    Back to the purpose of this note.

    I'm posting a request in the "appropriate" notesfiles requesting that
    field people with a need for TCP/IP support for VMS DECwindows reply to 
    this note with the size of the opportunity and the impact should we
    decide to *NOT* provide it.

    Please note that the only option for a VMS customer who MUST have TCP/IP
    support for X is currently to abandon VMS and buy ULTRIX.  If the "not
    invented here" syndrome wins out over market/customer demand, then we
    may learn a lesson the hard way.

    g.

Let's try to deal with reality a bit here.  I won't say NIH does not exist, but
there are more problems than most people imagine.  For example, .5 says, and I
quote:


    Please note that the only option for a VMS customer who MUST have TCP/IP
    support for X is currently to abandon VMS and buy ULTRIX.
    -------

Note the word SUPPORT.  Support does not mean "give them some software that
seems to work".  It means "give them some software, promise that it works to
the best of our knowledge, and if it does not work, promise to fix it to the
best of our ability."  Therein lies the rub.  No one argues that TCP is not
important.  No one argues that we should never have it.  What we do argue is:

	1.  If you want to operate DECwindows between VMS systems, you
	    can use DECnet.

	2.  If you want to operate DECwindows between VMS and Ultrix,
	    you can use DECnet.

	3.  If you want to operate DECwindows between VMS and anything else,
	    you have to use TCP, but we can't tell you that it will work
	    because we have not tried it, say nothing of tested it.  Neither
	    can we fix it if it breaks since we don't have the hardware or
	    expertise to run on other types of systems.

Note that 1 and 2 provide no compelling reason to support TCP.  3 is the only
reason, but as I explained there we can't really "support" it.

Please understand that we are not ignoring the need for TCP support.  We have
spent hundreds of person-hours over the past several months trying to figure
how we can do this.  We are still trying to figure out how to do it, as a matter
of fact. It is simply not as simple as dropping the code on a tape
somewhere.

Burns

>Please understand that we are not ignoring the need for TCP support.  We have
>spent hundreds of person-hours over the past several months trying to figure
>how we can do this.  We are still trying to figure out how to do it, as a matter
>of fact. It is simply not as simple as dropping the code on a tape
>somewhere.

    You have a good point, Burns, but what I mean by "support" is simply
    implement.  In the good old days, DEC shipped all sorts of stuff with
    VMS to test the waters.  I was considered a rebel in our shop (MGH) 
    because I used the (*gasp*) unsupported KED hack that became EDT.  I
    just couldn't deal with SOS.  Although EDT was unsupported and modal,
    I PREFERRED AN UNSUPPORTED SOLUTION RATHER THAN UNACCEPTABLE ONE.

    I believe that, while there are customers that will avoid unsupported
    features like the plague, there are alot out there that would do 
    anything to be able to hook all their workstations together.  I did
    a survey when I was with BPM of about 600 customers who attended 
    DECwindows seminars.  Less than 5% had only VMS workstations in their 
    shops.  Experts say that over 75 % of the workstation market does NOT 
    run VMS and DECnet.  

    I am suggesting is NOT to bring all the wonderful quality and robustness 
    and full documentation to bear.  What I'm asking you to do is:

        - throw it on SOME kit and DO NOT document it.  Specifically state
            in the documentation that only DECnet is supported.

        - re-post the note from the old conference that states what to do
            to make it work.  Add that you CAN tell customers about it IFF
            they understand that it is not supported.  I heard that DWICS
            went out on some field test kits; what is the diff?

    Accounts that avoid unsupported software will never know it is there.
    Accounts that don't need it will never know it is there.
    Accounts that DESPERATELY need it and aren't squeamish will use it.

    But this is only an interim solution.  Hopefully you'll find a way to
    support it.  Talk to Phil Auberg about all the arrows he got in his
    back at the Worksystems Update Symposium last summer about this.  No
    matter how hard or painful, we need to do this.  First, as quickly as
    possible and THEN figure out how to do it right.

There has recently been some discussion about this on comp.windows.x.
Some of the statements made there have roused my curiosity.  Some of them
make very strong cases in favor of getting something out there soon.

o Several people have indicated that the TCP/IP tranport library that
  we have will only work with the CONNECTION software.  Is the programming
  interface to CONNECTION different than to Wollengong or Excelan?  If
  so, who should be responsible for supplying a transport image for these
  products DECwindows or the vendors of the TCP/IP package?

o Many people complained about the lack of features in the CONNECTION
  software.  They claimed this lack forces them to use other vendors.
  If they are (even in the interim) using these other TCP/IP packages,
  how should they expect to get a DECwindows connection through them
  (see above).

The issue has been mostly flame on the usenet but it has recieved substantial
traffic.

Dick

    Please note that VMS realized pretty much from the word go that TCP
    support was a requirement.  The transport interface was designed as
    plug-in-at-runtime-dynamically because of this recognition.  VMS also
    realized that it's expertise was not in TCP.  At least as far back as
    the Sept '87 VMS Project Plan is the statement:

     *	TCP will not be supported by VMS.

    and another statement:

     *  TCP support is an issue, it needs to be supported.

    (These aren't exact, just the basic points made in the plan.)

    Because VMS supports SET HOST doesn't mean it should support SET HOST
    for X.29.   Similarly, because VMS supports X11 doesn't mean they
    should support every transport in the world.

    So, while you may choose VMS to request this support, the astute
    readers will realize that this might not be the only place to take
    their requirements.           

    re: .7

     >   - re-post the note from the old conference that states what to do
     >       to make it work.  Add that you CAN tell customers about it IFF
     >       they understand that it is not supported.  I heard that DWICS
     >       went out on some field test kits; what is the diff?

    Please note that VMS product management does not look upon giving
    customers unauthorized software "favorably".  In fact, they consider
    theft of property from Digital.  Do you feel comfortable walking out of
    your building with a terminal and giving it to a friend?

-< But what doe we do about talking to X terminals that only support TCP/IP? >-

Jake,

What do we do when Digital decides to offer an X terminal that supports 
only TCP/IP. Such a possibility exists and is more than idle chatter in
marketing's mind. We really need a viable TCP/IP support for VMS. 

James

>o Several people have indicated that the TCP/IP tranport library that
>  we have will only work with the CONNECTION software.  Is the programming
>  interface to CONNECTION different than to Wollengong or Excelan?  If
>  so, who should be responsible for supplying a transport image for these
>  products DECwindows or the vendors of the TCP/IP package?

    I don't do answers, only questions: I'm no longer corporate ;-)

    There are some answers to your questions in the UCX notesfile (kp7 etc).
    In fairness to that product, the primary purpose was to provide a way
    for VMS Clusters to serve UNIX workstations.  Then, after the product
    was well into field test, everyone started wanting everything else even
    remotely connected with TCP/IP.  That crew has done a great job of V1.
    Future versions will be even better.  As far as support of other TCP/IP
    implementations, I don't see why it should not work, if we have truly 
    implemented the standard faithfully.  If not, we should fix this.  What
    good is a standard if you break it?

    Gail/Burns,
    
    I am in the EDU group, marketing workstations to universities. We
    have a surprising number of VMS fanatics left, many of whom have
    VAXstations (about 2500 VMS VAXstations in US Universities). They
    HAVE to communicate to TCP nets. They have been using Wollongong
    and the like, but hav been asking for a DEC TCP VMS product for
    some time. They look on the VMS/Ultrix Connection as a God-send.
                                          
    The continuing effort by DEC to make it easy for VMS to co-exist
    with the rest of the campus computing environment is critical for
    these folks to be able to keep using VMS. This is a big part of
    the DECwindows story for them. That story is greatly diminished
    if they can't use TCP. DECnet/Ultrix is not bundled with DECstation
    3100, and likely will not be bought on most systems. And clearly
    the Suns, HP etc stations around campus don't run DECnet. In fact,
    most of the 1500-odd Ultrix VAXstations on campus don't run DECnet
    either.
    
    The bottom line is that for the University market, VMS/TCP DECwindows
    is a critical part of maintaining the VMS base.
    
    Bill
    

< Note 29.9 by TREADS::VANNOY "Jake VanNoy" >
              -< VMS isn't the only place this could be done... >-

>   the Sept '87 VMS Project Plan is the statement:
>     *	TCP will not be supported by VMS.
>   and another statement:
>     *  TCP support is an issue, it needs to be supported.

#define FLAME_ON 1
#ifdef FLAME_ON

    Sorry.  This argument doesn't wash with me.  The problem is VMS's problem,
    like it or not.  If you can find someone to do it and support it for you, 
    great, but the screaming customers are saying bad things about 
    >>YOUR PRODUCT<<.
    If you don't have the expertise, fund the people who do.
    
    I've been fighting this for a long time, Jake, and haven't been doing it to 
    be a pain(I'm that naturally).  I've been fighting because doing TCP/IP is
    doing the right thing and I believe very strongly in that.  As far as 
    "stealing" software, I'm offended.  I will not comment.  I simply referred 
    to historical FACT of EDT/KED in early VMS being unsupported.

    #endif
    #undef FLAME_ON

    g. 

I think you're wasting gasoline.  People like Jake, Burns, and Monty have been
raising these kinds of issue all along.  Thanks to Monty, the arguments about
technical feasibility are moot; it can be done and it does work.  I use it
exclusively between my `vs2000-decterm' and my 8550 timesharing system.

While one might argue that VMS should support TCPIP transport for DECwindows,
and that it follows that VMS should support TCP/IP, and then it follows that
VMS should support TELNET, FTP, SMTP, and then it follows that VMS should
support IMPS and backbone gateways, and probably VMS support make sure that
TCP/IP is properly supported on Sun, Ultrix, etc.

Somewhere the line must be drawn; VMS can't and should be held responsible
for everything.

In this case, one rather logical solution is to bundle it with Connection
and make them responsible for ensuring that the various issues get resolved.
I think that another possibility is to make this available to SWS so they
can adapt and sell and support it (via ASSETS?).

But the most important step to take has been done by only a few, document
the lost revenue/sales/account good will and make sure that the appropriate
product managers have that information.  If the problem is as critical as
implied, then there should be little difficulty in doing this and the results
should be almost automatic.

RE: university

And remember, what students use on campus they want to use later on the job,
witness UNIX...  

Chad

    
    re: .15.
    
    i think all people are asking for is TCP/IP transport support for
    DECwindows.  nobody expects VMS to provide all of the other things
    mentioned.  i mean, then VMS might actually then be useful :-)
    
    this argument really doesn't make much sense to me.  the world (at
    least workstations) is IP.  some day (5 years), the world might be OSI.
    i presumed that the oversight in not having IP support for DECwindows
    for VMS was due to time constraints, not some philosophical reason.
    
    what is the purpose of all this standards and interoperability hoopla
    (OSF, POSIX, etc) if VMS can't do it.  it seems to me that it is in the
    best interest for VMS to do this -- make VMS work in a heterogeneous
    environment with suns, etc. using XUI.  that measn IP, like it or not.
    
    by the way, my customers are assuming that IP support is down the road
    somewhere.  during the long period of DEC decline in the workstation
    world, they bought a lot of suns (100's).  now, they are excited at
    the possibilities of integrating their large VMS base of machines,
    using the suns as servers to their VMS clients.  in addition to this,
    they are buying ds3100's as their next series of machines.  the comment
    about dumping VMS for Ultrix is not mere whimsy -- if they can't
    integrate the VMS machines in the environment, they will investigate
    porting to Ultrix as a solution (they've done it before).  this really
    doesn't bother me, being a Ultrix PSS person (more work, more $$).
    the trend for this customer (DOD) is to do ALL new development and
    research on UNIX (Ultrix mainly).  in order to justify the use of VMS,
    you have to get God's approval (no joke) -- it just isn't a solution
    unless any form of UNIX will not work.  the lack of IP support for
    DECwindows is just another nail in the coffin, in my opinion.
    
    just a few rambling musings from the field.
    
    -paul 

    Re: .13
    
    I work in industry marketing responsible for marketing Digital's
    networking & communications products into the education market. 
    
    The failure of VMS DECwindows to support TCP/IP as a transport option
    SOON will hasten the demise of VAX/VMS based DECwindows workstations
    and VAX/VMS based DECwindows client systems in
    university community. There is a growing trend in universities to
    support ONLY TCP/IP PROTOCOLS on the campus backbone (and probably OSI
    protocols in 3-5 years when OSI implementations have appeared and
    interoperability has been proven).  As this happens DECnet (Phase IV)will
    be relegated to a local, departmental protocol.
    
    As Bill pointed out in .13 there are lot of customers who like VMS, in
    fact prefer it over U*IX. Failure to provide TCP/IP as a transport
    option, when the campus network is TCP/IP (and I should point out that
    the national networks are TCP/IP as well), will force these customers
    to move to U*IX in order to particpate. Also, failure to support TCP/IP
    as a transport option on client VMS client systems, will shut off any
    opportunity to sell/install systems which provide VMS-based client
    services, either Digital's or third parties. 
    
    Michael

    re:17
    
    Paul is absolutely on the nail with his comments. DOD has commited
    to go with OSI..WHEN it's available. In the meantime, we've been
    making progress in the govt. sector moving them towards Posix. Of
    course, anything that doesn't support their comms architecture,
    isn't of any use whether it's Posix compliant or not.
    
    Make all things equal (TCP/IP on both Unix and VMS) and we can state
    a pretty good case with the government for going to X windows. When
    both are Posix compliant, it really won't matter (will it?) what
    the underlying OS is. Take away all their arguments for why they
    need to go Unix and they will be willing to listen why VMS might
    suit their needs better.
    
    Taking a different approach, if X had existed several years ago,
    VMS Posix compliant (assuming such a standard existed), VMS might
    have become the defacto standard with its rich networking capabilities
    and we all may have never heard of TCP/IP. I see X as the opportunity
    for VMS to regain the ground it's lost to Unix. We must start on
    equal footing though (i.e., TCP/IP).
    
    Lastly, I worked for Paul's customer as a civil servant for 20 years
    pushing UNIX for a good portion of my career there. What he says
    is no bull!                         
    
       Al

    Can't believe we're still debating this...
    
    Required:  Ability to transport DECwindow goodies via X-protocol
    from a VMS based cluster to non-DEC equipment.  Does this require
    "FULL" TCP/IP?  You tell me.  Could we have a "3rd-party" organization
    deliver it?  You tell me. Is the customer base demanding it?  I'll
    tell you.
    
    I have a wide variety of customers in the SCA who bought the idea
    of a heterogenous compute environment.  They have been around awhile,
    and bought SUN's and Apollo's when that was the only solution. 
    They cannot afford to throw their old equipment away just because
    DEC now has the best thing since sliced bread.  They're stuck. 
    It's like the old argument of do you put a workstation and a PC
    on everyone's desk, or do you integrate them into a single device.
    "If they want Bookreader capability, then buy a DEC workstation."
     Otherwise, keep on using the thousand's of Sun's you have on your
    desk right now and don't come crying to us because you bought the
    wrong computer.  We don't integrate you VAX/VMS cluster with your
    desktop.
    
    I think I need to re-think about the idea of telling my customers
    about heterogenous computing and protecting their investment.
    
    Oh yeah, the list of accounts:
    
    						     WORKSTATIONS
    Company		     VAX/VMS CLUSTER    SUN's  Apollo's    DEC
    ----------------------------------------------------------------------
    Major electronic firm:	Several		1000's	 <1000	   <100
    Major oil company		Several		 100	    50	    150
    Major Aerospace Contractor	BIG BUNCH	1000+	 <1000	   <100
    Major Software Deve. Co.	Would buy if...	2000+	 <100	   none

    
    Each of the accounts listed are Fortune 50 accounts.  They buy big
    and they buy a lot.  They don't believe DEC has all of the answers
    but they do like the story.  They aren't going to throw away their
    investment,  even for us.
    
    If we ain't gonna do it, then publish the specifications so a 3rd
    party can provide the hook.  That way if it doesn't work, we can
    point the finger at them.

I don't think anybody has argued that we should not support TCP/IP from VMS.
We already do in a limited way and more capabilities are coming.  What has
been argued is when TCP/IP based X Protocol Transport shoulld be available
from VMS.  I hope that this is high on the list of things for the next release
of either VMS/DECwindows or UCX (which ever comes out first  8^{).

The other question I still have not seen answered is whether the programming
interface to UCX is the same as Wollengong and/or Excelan.  My understanding
(which could be completely wrong) was that the programming interface was
not part of the spec.  If that is true then there is no guarantee that any
OEM supplied TCP/IP could be substituted under the TCP transport shareable.

Dick

				DIGITAL CONFIDENTIAL
				FOR INTERNAL USE ONLY

	In an effort to give this component as much internal testing as
	possible, we are making an *UNSUPPORTED* version of the DECwindows
	TCP/IP transport available.  This image is not a part of the
	SDC DECwindows kit and there are no commitments for its inclusion
	or for any support.  We are interested in having it exercised in
	mixed-OS environments and in *informal* reports on its benefits,
	performance, problems, and outright bugs.  Please be aware that:

		1)  THIS SOFTWARE IS UNSUPPORTED and,

		2)  IT IS NOT TO BE RELEASED OR SHOWN TO CUSTOMERS.

	Instructions for installing and using the transport follow.


	Instructions for an informal, *unsupported* installation of the
	DECwindows TCP/IP transport.

	o  Install the SDC/V51 version of DECwindows.

	o  Install the UCX Product.  See the (Lassie::) Connection notesfile for
		details on kit location, registering internet addresses,
		etc.  See notes 128.1-128.3 in the (NaC::) Ultrix notesfile
		for information on internet network administration.

	o  Copy TCP/IP transport image to target system/cluster.

		The current image is located on the vmskit:: (nee bulova::)
		machine as:

		Vmskit::Decw$Public:[Unsupported]Decw$Transport_TCPIP.Exe


		Target directory is SYS$COMMON:[SYSLIB] or
		SYS$SPECIFIC:[SYSLIB].  Target protection is W:RE.

	o  Edit Sys$Manager:Decw$StartServer.Com

		Add "TCPIP" to the value list assigned to the logical name
		"DECW$SERVER_TRANSPORTS".  I.e.:

		"$ decw$define decw$server_transports decnet,local,tcpip"

	o  Edit Sys$Manager:Decw$Startup.Com

		Add a command sequence to install the TCP/IP transport image
		using the DECNET and LOCAL transport installations as templates:

	$
	$ if f$file("sys$share:decw$transport_tcpip.exe","known") -
		then install replace sys$share:decw$transport_tcpip
	$ if .not. f$file("sys$share:decw$transport_tcpip.exe","known") -
		then install create sys$share:decw$transport_tcpip/open/share/header

	o  (Re-)Start DECWindows.

	o  Use the "Set Display <device>/Transport=TCPIP" command to use
	   tcp/ip for client connections.


					Notes:

	1.  tcp/ip does not support any notion of remote user.  If a workstation
	    user wishes to allow connections from a node using tcp/ip as the
	    transport mechanism, the user must wildcard ("*") the user field
	    of the user entry in the session manager's security menu.

	2.  Case is significant in tcp/ip nodenames.  It is recommended that
	    the local host database be configured with uppercase aliases
	    for defined nodes.

	3.  If a connection is received from a node where there exists no
	    address-to-nodename translation, the remote note will be repre-
	    sented by the textual form of the internet common address.
	    For example, a connection from node "scylla" to a system with
	    no knowledge of scylla would be represented by the string
	    "130.180.4.250".  Security selection should take this into
	    consideration.

	4.  Similarly to 3., a client may refer to a server using this
	    address format.  A "Set Display/Node=130.180.4.250" will cause
	    a DECwindows application to attempt to connect to node scylla.

    Can't a natural analogy be drawn to the IBM Interconnect Strategy?
    Where a de-facto standard exists (SNA) we've moved in to provide
    the best interconnect products in the industry; many have said they're
    better than IBM's!!  No, we don't support MVS, CICS, VTAM, etc,
    just the best means of talking to them.  With these products, DEC
    opened whole new markets for its entire line of products.
    
    The same opportunity exists for customers with big investments in
    TCP/IP.
    
    Look at the DECwindows fluff diagrams: they have Cray, IBM, and
    all kinds of other boxes, connected in such a way as to give the
    impression that DECwindows will address every kind of 
    interoperability scenario.  Without support for TCP/IP, this is
    a bald-faced lie.
    
    << Tim >> 

In case it isn't apparent while reading this, it is a flame.

A little while back someone complained that if a customer reported
a bug with an interconnection product, we couldn't help them because,
lets see... "we don't have the hardware to reproduce it."

Well then, I suppose the folks over in UEG had better stop supporting
TCP/IP protocols too, eh?  'Cause they sure ain't got one of
everything ever made.

Hmmm - and I guess the people doing the SNA gateway don't realize
that their jobs are impossible, unless their budget includes
enough for everything IBM et al put on SNA.

Give me a break!  Your complaint was just a whining excuse that
you're using because you don't want to do the work.  Tough
luck cookie: if you want to play in the "open" market (read:
"if you want anyone to buy your products anymore") then you
sure had better learn to support interconnecting software.

If our TCP/IP works between Ultrix and BSD and Sun, then I'd
generally be satisfied that it works.  If someone has a problem
that shows up between Ultrix and Sequent's Dynix, I don't always
need a Sequent machine to check out the symptoms.

Sometimes I will, of course.  Fixing bugs is a tough job (I'm glad
I'm not doing it for a living anymore :-).

What do we need for this product?  SUPPORTED connections between
VMS X clients and non-Ultrix/TCP servers, and vice versa.  If it
breaks, we figure out whether it's our fault or not and fix it.

If someone complains about the SNA G'way, do we point fingers at
IBM?  At the customer?  Not if we want to keep selling machines, and
not if we want our customers to stay happy.

Get off the typical VMS high horse and start dealing with real world
issues:  if you want to sell workstations, you've got to obey the
rules of an already established market, not those made up for your
own convinience.

We will now return you to your regularly scheduled temperature.

Flames such as those in .24 don't do anybody any good.  Obviously, you
haven't read any of the previous replies from folks in VMS Engineering who
*do* recognize the need.  It's a matter of having enough resources to do
what needs to be done in the amount of time given.

I don't understand how some people get off by flaming at the VMS folks.
I don't really see how anyone outside that group could possibly have any
right to flame them for "not wanting to do the work", or could possibly
construe that attitude from their replies in this note.  Oh sure, they don't
want to do the work... they just spent all this time taking the standard
X base on Unix, porting it to VMS, providing DECnet support, providing
utilities and applications on top of it, etc. etc...  And it's great to see
that we now have a product where VMS and Ultrix can coexist in harmony.

And no, I don't work for VMS Engineering, but I do appreciate their work.

-Shawn

re .25:  Thanks...you saved me from embarassing myself responding to .24.

Burns

RE: .24

There have been plenty of cases of NIH syndrome in VMS Engineering, but TCP/IP
support isn't one of them.  Before you go off on tirades like this, remember
that UEG didn't have to write the TCP/IP code--it was already a part of 4.2bsd
Unix.  All Ultrix Engineering has had to do with it is fix the occasional bug.
VMS has (1) had to write the code (Ultrix Connection) from scratch, and (2) had
to do that in parallel with DECwindows development.  Consider also that both
the quality and support expectations are higher for VMS than for Unix/Ultrix.
It takes much less manpower to fix bugs in already working code than to
develop things from scratch.

The manpower really, truly was not there for DECwindows V1.  TCP/IP support
should be a critical item for V2, if not a V1.n.  Flaming in notes conferences
will not make this happen.  Making the DECwindows product and development
management aware of the critical business need will.

--PSW

    
    Paul,
    
    I thought the UCX product was *funded* by UEG - no?
    Also, if IP code is written in the C language, then
    it should not be too hard too move it over to VMS - 
    but then, what do I know? ;-)
    We have customers who will pay good money for an industrial
    strength VMS X11 product that has multi-vendor interoperability
    capability in the first cut (ie, v1.0).  Could we have used the
    anticipated revenue shipment $$$ figures to hire C programmers
    to do the VMS port, to obviate the manpower shortage argument?
    The opportunity cost ratios plus the revenue synergies ( VMS and
    ULTRIX marketing messages centering around interoperability) are
    too good to make this a VMS versus ULTRIX issue.  Afterall, our
    paychecks come from the same focal point ;-)
    
    I believe product management has been aware of the big gap in the
    VMS offering for sometime time now - what is needed now is a big
    crane to move the people in-charge.
    
    								kris..

re .28:  Most certainly VMS Product Management (as well as VMS Engineering) has
"been aware of the big gap in the VMS offering for sometime time now".  We
yelled and screamed years ago.  Our Phase 1 documentation said clearly that
TCP and interoperability were important, but we would not be able to do it
ourselves.  We requested help.  We asked over and over again for a group to
be chartered to do interoperability testing.  We did not even get someone
to do testing with Ultrix, say nothing of someone to test against other
manufacturers!

In the ideal world, we would have all the people we needed to build everything
we want to build and support everything we want to support, and all in time
for the next version.  Unfortunately, this is the real world.  Even if we had
the money to add n people to the group to do this work, we don't have offices
for them to sit in.  We might be able to get some big customers to fund a few
people to do the work, but would they build ZKO4?  (Last sentence is a :-) )

In any case, lots of people are trying to see what can be done.  We hear you;
it's just not as easy as it seems.

BTW, in case someone thinks that testing is a red herring, I have heard from
at least two different sources that, in fact, the server really does not work
with at least two foreign clients running DECnet.  This is why we don't promise
things that we have not tested.

Burns, who will try not to get sufficiently provoked to make any more responses
	to this topic.

re the flame-tossing:

Burns - when I asked field people from WS_COMPETITIVE_FORUM, DWT, ULTRIX,
UNIX_WS and UNIX to respond, I did not ask them to flame, I asked them to
give CUSTOMER DATA.  What you are seeing is the result of the arrows that
the sales support people have gotten for NOT having the hooks there.  
What you may not realize is what it is like for those people.  They are on 
the firing line.  They have battle-scars from this lack.  To give you an 
idea of what it is like, imagine the response peoples gave at DECUS due to 
the lack of IP support in DW and then imagine getting that weekly....

I was not out to get anyone mad.  I was out to get you DATA to help with the
fight and to up TCP/IP in the queue of things to do.  I also know, from 
being back there, that the connection people were willing to help, but it
has to be a joint endeavor: both sides giving alittle. The best thing about
DEC is when people put aside their differences and "do the right thing",
even if it means extra work or extra hours, simply because it IS the right
thing and should be done.  And sometimes even take a chance, just because
it is the "right thing to do"....

In case anyone forgot, I'm the person that flamed back a few notes ago.

I posted a different (and quite mild) reply in one of the other notesfiles
as well as sending it to the person suggested for input.

I probably shouldn't read conferences that have both VMS and Ultrix content
in them, because it makes me combative.  (Just like driving does...)

I apoligize for the rabid tone that I used before; it was an overreaction
to a few comments made in these replies that were probably not the correct
portions to focue on:  I do realize how difficult it can be to test
interconnectivity tools, and I very well realize the political problems
that can occur when someone gets into such a scenario - I was covering
software for berkeley when they claimed to have found some bugs in Ultrix's
Internet code that UEG said was probably in Sun's code.  No one ever solved
the problem, it just went away with the changing versions.  (Probably
version skew as both Ultrix and Sun tried to use more of the 4.3 ip code).

But the NIH syndrome sometimes appears to have been invented at DEC -
probably less at Spit Brook engineering than at some unnamed marketing
offices.  It's painful to try to convince an organization that a market
is headed in the other direction than the one they're looking in.  And
when it seems to be happening again, and again, I over react.

I believe that VMS+DECwindows people understand that TCP/IP (and more 
broadly, generally adaptable interconnectivity) is a market requirement.
And not having it in the first version or two is acceptable.  But my
customers are correct when they state that not having any plans for
such a capability is unacceptable, and they won't buy it.

Of course, in DEC, "not having any plans" doesn't mean not having any
plans.  It might mean having too many plans, or just being scared about
committing to plans, or not having the resources to fund the correct
plans.

I flamed at the wrong people.  DECwindows is a great product (surprised
the hell out of me, I was all set to hate it).   The first version is
a tremendous win for DEC, and with OSF/Motif, it should be quite a 
benefit to the market as well.  Keep up the good work and realize that
people way out here in the field have trouble discriminating between
the correct target and the available target.  It's that kind of company.

To come back to the initial purpose of this note:

Our customer, the corporate account SIEMENS AG, has in different 
departments the same problem to solve:

o  integrate hundreds of SUN or Appollo Workstations via powerfull
   data and applikation servers which supply additional services as:

   - communication to Mainframes
   - long term archiving (optical discs)
   - mail services
   - document management
   - "corporate publishing"
   - ect. ect.

	AND, a common user interface over all (Servers and WS) for 
        ease of use.

They have a lot of nice concepts in mind which conform with our 
stategies.....  

Now, it looks like we have it all. Optical discs, EDCS, SNA, FTSIE ect.
But, all this is available under VMS ONLY. ULTRIX-Connection does part 
of it now. DECwindows (with TCP/IP Support under VMS) would do the 
required rest.

Customer was very impressed by our newly announced workstations  
and by DECwindows concept. Up to now, they are not aware of "the devil 
which sticks in the detail". But I have to supply solutions. I know, 
that I will sell future. I'm sure, customer will accept "future", as 
long as I can give time frames...     

Elisabeth, SWS

    You wanted data, so here is data.... My customer, Shell Oil, is
    committed to a heterogenous workstation environment.  In the fall
    they thought that this was only achievable by re-writting all of
    their applications in some UNIX derrrivative and made a recommendation
    to their management regarding this.  Senior level Shell management
    thought it might not quite be time to throw VMS out the window.
    They requested a meeting which was held in Spitbrook on Nov. 12
    and was hosted by  Heffner, Riley, Freidrick and other high level
    folks.  "AIA" was talked about in detail as well as the difference
    between VMS and Ultrix.  "Interoperability" was discussed as well.
    No one from Shell thought to ask the question as to HOW would one
    use VMS to speak DECwindows to a SUN directly, but maybe they should
    have, or maybe I should have primed them.  When OSF made the OSF/Motif
    decision, Shell immediately approached me about getting the sources
    for XUI so that they could run it on their SUNS.  They have made
    the decision that VMS will not be tossed out today--- people like
    VMS, although new applications will be developed most probably in
    a UNIX environment.  These VMS machines will die a quick death if
    there is not a way to use TCP/IP with DECwindows.  Shell field tested
    the Connection product, but decided to use Wallagong until the
    Connection software is more robust.  They asked for TCPIP support
    for DECwindows in the questionairre for next release stuff.  
    
    I personally would like to continue to be able to sell VMS solutions
    to this account as there are a lot more layered products in this
    environment.  I am very happy that there are now Ultrix solutions
    I can sell.  But I sure dont feel real good about selling that
    "interoperbility" stuff if VMS is only interoperable through DECnet
    when in the workstation world TCP/IP is today's environment.  This
    capability should be supported and tested with our own Ultrix products
    at a minimum.
    
    Oh buy the way, in fy89 we will do a minimum of $4million in VMS
    workstation related products (ws, servers, and sw) in the US alone.
    Let's not help Shell nail the VMS coffin shut by giving them reasons
    why our interoperability story is full of holes. 
    
    Maureen                                     

I read about this topic in another notes conference asking for replies from 
the field, but I hope you do not mind one from a different marketing group.  I 
work in Engineering Systems Group and am the marketing manager for a Solution 
System targeting the electronics design market.  We are trying to get back in 
that market after finishing a dismal 3rd or 4th in the market.  Since we are 
trying to regain a market we once were dominant in I would like to be able to 
use the VAX VMS systems we have sold into those accounts, but I NEED to be 
able to coexist with the workstations the customers have been buying.

The Solution System is buuilt on a data management product that can be server 
and client on either VMS or ULTRIX, but they have not been able to get their 
own servers to work together if they are not working with the same network 
protocall.  The server on a VMS machine supports DECnet and the ULTRIX machine 
supports TCP/IP.  They did this because they thought DEC would be able to 
connect our own machines together.  We have had better luck tying a Sun to a 
DS3100 than a VS3100 to a DS3100.  ( Wouldn't you love to strangle the idiiot 
that named those machines?)  The solution system may work better with Sun's 
and Apollo's than with VAX VMS computers if Digital does bot find a good way 
of solving this problem.  

I am currently predicting only ULTRIX servers untill I see a solid resolution 
to this problem.  I am quoting over $70M worth of revenue for FY92 for the 
entire solution system, obviously this includes hardware and software and 
services.  It has raised eyebrows, though, to see a substantial plan for our 
historical target market in engineering with absolutely no VMS system revenue.

I would love to have the time to fight the battle in the company to get the 
support there for VMS TCP/IP DECwindows support, and I will support anyone 
with anything I have, but I am rather busy currently fighting other battles.  

Matt Haley

I'm confused.  You can run DECnet on Ultrix, so what's so hard about making
VMS talk to Ultrix???

	paul

    
    Paul,
    
    there is no big problem with ULTRIX/VMS interoperability if both
    systems run DECnet.  The problem arises when VMS tries to inter-operate
    with other non-Xobject/DECnet UNIX systems (including ULTRIX).
    
    VMS needs TCP/IP support *badly* to compete in the opens systems
    computing market.
    
    The revenue numbers are just too impressive - if we can make it
    happen right now.                                         
    
    								kris...

        @(#)README	1.3 7/13/88
 
	This directory contains an example of how an Ultrix system can
	be used as a gateway to swap transports for an application
	protocol.  For example, an X client on a TCP/IP only Unix system 
	might want to communicate with an X server on a DECnet only VMS 
	system.  Even though client and server both speak the same
	protocol (eg X11), the lack of a common underlying transport prevents
	communication.  However, if we insert an ULTRIX system with both
	DECnet & TCP/IP between the two, it can act as a gateway:
 
                     <------------ X11 ----------->
              +-----+  DECnet  +--------+  TCP/IP  +------+
              | VMS |<-------->| ULTRIX |<-------->| Unix |
              +-----+          +--------+          +------+
 
	What is needed on the ULTRIX system is a program which will swap
	application data from DECnet to Internet and vice versa.  The 
	program gatewayd.c performs such a function.  It employs 2 sockets,
	one in the DECnet doamin and one in the Internet domain. Once 
	the necessary connections are set up the operation of gatewayd 
	is trivial.  It simply reads whatever is available on a DECnet 
	socket and writes it to an Internet socket.  Similarly, it reads
	whatever is available on the Internet socket and writes it to 
	the DECnet socket.  The hard part is in arranging for the
	connections to be set up in the first place.
 
	There are 2 possibilities as far as connection establishment 
	is concerned.  One is that the client is on the VMS system
	and wishes to communicate with a server on the Unix system.
	The other possibility is that the client is on the Unix system
	and the server is on the VMS system.
 
	In the first case (VMS-->Unix), the VMS client will establish
	a connection to a specially defined object on the ULTRIX system
	which will invoke gatewayd and arrange for it to connect to the
	desired server on the Unix system.  The following example details
	the steps involved for an X protocol gateway.  The procedure
	for other protocols would be similar.  All steps are performed
	on the ULTRIX machine which is acting as a gateway.
 
	   1)	Define a new object in the DECnet object data base.
 
		When using DECnet, X clients request connections 
		to objects named X0, X1, X2, etc., where each object 
		corresponds to an X server on a given machine.  A single 
		user workstation would have normally have a single server 
		called X0.  A dual headed workstation would have 2 servers 
		called X0 and X1.  Pick a name that is not already in use 
		(eg X2) and define it with an ncp command such as that 
		shown below:
 
		  ncp set obj X2 file /usr/etc/xgate2 type stream \
		  default user guest
 
	   2)	Create the file specified in the ncp command above.
 
		The file will be a shell script which invokes gatewayd with
		the appropriate arguments.  Program gatewayd takes three
		arguments: the type of socket to use for the second half
		of the gateway connection, the node to connect to, and the
		name of the service desired.  Suppose we want to use the
		first X11 server on node allfelt.  The file xgate2 would
		look as follows:
 
		  #! /bin/sh
		  exec /usr/demo/gatethru/gatewayd -inet allfelt X0
 
	  3)	Define the service X0 in /etc/services.
 
		X11 servers use port numbers 6000 and up (ie. the first
		server listens on 6000, the second on 6001, etc).  X10
		servers use ports 5800 and up.  Since we want to connect
		to the first X11 server, add the following line to
		/etc/services:
		
		  X0	6000/tcp	# X11 server port # for 1st display
 
	Set up is now complete.  The VMS client is invoked to use the
	X2 display on the gateway.  What it actually ends up using is
	the X0 display on the Unix system "allfelt".
		
	The second connection possiblity is client on a TCP/IP only
	system connecting to a server on a DECnet only system.  Once
	again using X11 as an example, the steps are the following:
 
	  1)	Edit /etc/services
	
		Pick an X11 port number that is not in use and some
		identifier to associate with the VMS node where the
		desired X server resides.  For example, if we want
		to connect to the first X11 server on VMS node vmsnod
		the following line would be added to /etc/services:
 
		  vmsnod-X11-display0	6002/tcp  # X11 server, 1st display
 
	  2)	Edit the file /etc/inetd.conf
 
		We need to establish a connection between the identifier
		"vmsnod-X11-display0" entered into /etc/services above
		and an invocation of gatewayd with appropriate arguments.
		This is done with an entry in inetd.conf:
 
		  vmsnod-X11-display0 stream tcp nowait \
		  /usr/demo/decnet/gatethru/gatewayd gatex -dnet vmsnod X0
 
	  3)	Re-init the inet daemon.
 
		This can be done by sending it a HANGUP signal, killing
		and restarting it, or rebooting.
 
	Set up is now complete.	 The Unix client is invoked to use the
	second display on the gateway.  What it ends up using is the
	first display on vms node vmsnod.
 
 
	FILES IN THIS DIRECTORY:
 
	README		This file
	gatewayd.c	Source code for gatewayd program
	makefile	Makefile for gatewayd
 

    Bidding Federal government programs often is an integration nightmare.
    With the interconnection of TCP/IP which is usually mandated by
    connection to the Defense Data Network, having a TCP/IP X.11 connection
    really means that VAXes can be placed for servers and disk farms
    rather than SUN servers.  In addition, there are commercially available
    X window terminals that use TCP/IP but have the high resolution
    monitors that are sometimes required for compliance.  In addition,
    it would be nice to allow those GFE (government furnished equipment)
    workstations to be upgraded to utilize X windows rather than Telenet
    or Rhost protocols which can be cumbersome.
    
    To ramble further, since SUN's NFS is supported by the VMS/Ultrix
    connection software, it would be embarrasing for SUN to come out
    and say that their workstations connect better to everyone else
    than DEC's.
    
    
    Mark King
    

Re-posted here for your reading pleasure....

      <<< HARBOR::DISK$USER2:[NOTES$LIBRARY]WS_COMPETITIVE_FORUM.NOTE;1 >>>
                       -< Worksystems Competitive Forum >-
================================================================================
Note 628.1              TCP/IP Support for VMS DECwindows                 1 of 1
TRILGY::GAVIN                                        19 lines   6-FEB-1989 18:39
                  -< TCP/IP Support for DECwindows under VMS >-
--------------------------------------------------------------------------------

I have several customers who will need TCP/IP support for VMS both in a 
development environment and , particularly for OEMs , in a resale environment.
I will be trying to use both DECwindows and Pvax and Pmax to surround Sun
workstations in a hetrogeneous environment and I would like to tell my customers
that they can open a window on a UNIX machine without having to buy the Ultrix
bridge product.
	If this functionality is not available then customers would feel that
DECwindows is not the open product we describe it as and would view a VMS /
DECwindows solution as propietary. This is exactly how the Sun sales rep would
attack our solution and he would most probably be successful.
	By giving TCP/IP support under VMS we can overcome another of SUN's
arguments about our openess and then sell the benefits of the bridge product
in terms of using the cluster support and high bandwidth of DEC's BI machines
and the strength and flexibility of DECnet in effecting a good transparent
sharing of data between VMS and ULTRIX machines and thus help to get rid 
of many SUN machines which have been able to penetrate VMS accounts by offering
DECnet capabilities. Lets beat the "OPEN "company at their own game.
	In terms of business I can think of about 100 - 200 workstation sales
that could benefit from having TCP/IP support under VMS.

re: .37

    Well the single-handed slayer of dragons bits and the writer of Xnotes for
    Ultrix(soon to be Dxnotes, right Matt?) has come to the rescue again.

    Please note that, thanks to Matt, we have an interim solution we can 
    suggest to our VMS customers: 

    Buy an Ultrix machine w DECnet to act as a TCP/IP gateway between the 
    rest of the world and VMS, until such time as VMS works out the support 
    details of supporting alternate protocols.

    g.

    re .40:  Please note that we make no claims that the solution in .37
    will work (i.e. that the VMS server will work properly with, say, a Sun
    client).  In fact I have a QAR saying that a f.t. customer did just
    this and it did not work.
    
    Burns
    (oops, I said I was not going to write any more here didn't I?)
    

RE: .37, .40, etc.

It constantly amazes me how often Digital seriously suggest that a customer
should solve a problem by buying a kludge configuration and hoping that we've
done the job good enough that it will work in the unsupported configuration.
Why not just do the job right - it'd be easier.

James

We can't change what we've already shipped, but we do have a kludge that will
work as well as what we could have shipped if we had more time.  Come on, cut
some slack.

BTW, is anyone using DECwindows TCPIP transport on VMS besides me ?

I use it every day all day for 4-10 TCP/IP sessions from one VMS system to
another.  My only complaint is that when one node or the other crashes, the
system is able to reboot faster than the link will timeout.  However, if
you are plagued by flacky networks, that might very well be a plus.

re: -1

I use it most of the time, but usually between ULTRIX and VMS. But on occasion,
I use it between VMS nodes.
					Jeff

Yes, enthuasticly yes. I often use the TCP/IP support on VMS to access our 
DECstation 3100 (PMAX) since it currently doesn't have a DECnet transport.
(I suppose simply because we haven't gotten it yet.) The performance is on
par with the VMS-VMS DECnet performance (subjective, not an actual measurement)
and works quite well.

James

DECnet has been available for the PMAX since FT1.  You can get it off of NETRIX.

See Note 2 in the [NAC::]DECnet-Ultrix notesfile.

    Please help a poor workstation sales rep understand...
    
    When a customer asks me how to hook his VMS machines into a TCP/IP
    network, I (think that I) can recommend one of the following:
    
    1) VMS/ULTRIX Connection (and get NFS, too).
    
    2) Fusion TCP/IP  (NRC)
    
    3) WIN/TCP or TCP/IP (Wollongong)
    
    4) ULTRIX machine as gateway (a la reply .37)
    
    5) Excellan 
    
    6) Public Domain Stuff (Carneggie-Mellon, etc.) and others we don't
    sell or support.
    
    Now the question: Regardless of the fact that the customers we have around
    here (especially the Boston educational community) all seem to think
    that options 1-3 all stink, and that nobody's tried 4, do we TODAY
    have a way to _XWindow_ between VMS and TCP/IP-land THAT WE CAN 
    OFFICIALLY SUPPORT???
    
    I ask this because I'm not sure what the difference is between
    "supporting TCP/IP on VMS" and the first few options above; all
    I care about at this point is what we can OFFICIALLY support to
    address the opportunity/problem.
    
    <<< Tim >>>

    
    1.  Can we support tcp/ip on VMS?  Yes, buy connection.
    
    2.  Can we support tcp/ip on VMS DECwindows?  No, it's not supported.
    
    					monty

    I didn't see a referance to 'Connection' on page 44 of the Feb 13, 1989
    Competative Update where it shows that it supports TCP/IP. Is that
    what they mean, or are they refering to VMS versus Ultrix?

							    Jens

    I'm doing a DECwindows road show for most of this month. I've been
    telling people that ask for TCP/IP transport on VMS DECwindows to call
    Colorado and file a SPR. Our customers are unhappy about this - small
    and large.
    
    Is there documentation available anywhere that can be used to build our
    own transport image? I tried quite some time ago and found the
    definition macros weren't in STARLET or LIB - has this been fixed? I'd
    be willing to do my own and ship it via ASSETS if necessary...
    	-Rick

    In reply to whole issue of TCP/IP VMS Decwindows support and
    specifically 29.13 -- the universiety marketplace (I can speak for
    CMU and Stanford) NEEDS THIS CAPABILITY.  29.3 notes that for VMS
    to Ultrix one uses DECnet -- the universitites I've dealt with don't
    want another protocol to support - they have committed to TCP and
    the VMS folks (yes there are alot of them out there) are isolated
    or must rely on inferior third party solutions.  The VMS/Ultrix
    Connection was what we hoped to be the answer -- but w/o the above
    capability its not the answer...........hard to put a dollar figure
    on this type of thing - but it will make a difference.
    Thanks
    Cinda George
    Stanford Account Manager
    

Well, now it's off to convince my PMAX system manager that he really should 
install DECnet for the PMAX. 

Thanks, I knew it was around, just our system doesn't always get the latest and
greatest.

James

    re .50:  tcp/ip for decwindows is a two-step process:
    
    1.  tcp/ip for VMS.  This is the Connection product available as a
    layered product (header files/macros/.r32's included).
    
    2.  tcp/ip "glue" for VMS Decwindows.  This is an unsupported product
    for internal use only at this point.
    
    					monty

Monty,

I think that .50s question was whether their was sufficient documentation
for him to write his own.  That would allow an interim solution for his
customers until the official solution was available.

Dick

    
    Ah, if that's the case then perhaps.  It doesn't exist at this moment
    but we are working on a document that would allow customers to use this
    unsupported and guaranteed-to-change interface.  And, no, I don't know
    when it will be available.
    
    						monty

I would second the need for a document that tell users how to "roll their 
own" protocol support.  There are alot of strange or slightly altered 
protocols and the ability to say, "we don't support <blah> right now, but if 
you would like to write your own (or pay SWS big bucks to do it for you), 
then refer to document <blah>" would at least give us SOME way out.

Last winter I was out doing the "Windows and Worksystems" Roadshow, an event
where we told 5,000 of our closest US customers, under non-disclosure, that 
DEC was implementing X across our platforms and were committed to it. I had
tons of folks coming up with questions of how to support stuff I've never
heard of(not difficult, since I am NOT a protocol kind of gal).  

Tell us how to shoot ourselves in the foot, if you won't do it for us.  Docs
might have also helped to ameliorate the flames here and then Burns wouldn't 
be all mad at me for raising this ruckus and refuse to write to this note
anymore :-(. 

g.

I'm not mad at you (see, I made an exception for you to make this reply :-)).
I'm just not going to keep responding to flames, having explained our position
rather thoroughly.

In fact, documenting the interface is probably one of the best options we have.
We have always planned to, but we did not do it in V1 for two reasons:

	1.  The ever present resource issue

	2.  We KNOW we are going to change the interface soon.  We are not
	    happy with it.  It has holes.  It WILL change.

It is beginning to look like (beginning!  Hah!  It has looked that way since
the beginning of this note) that maybe 2. is not a concern to a lot of people.

We'll see.  We do hear you.  You don't need to put any more testimonials of
how many hundreds of workstations this issue is preventing you from selling.
(Send them to product management if you feel the need to do something!)

Burns

    
    Attached are copies of mail messages from five different
    account managers I work with who were shocked to learn that
    TCP/IP was not a standard offering for VMS DECwindows.  Just
    add these to the pile of requests for this capability.
                 
    BTW: Just let me know if anybody needs more field feedback on
    this need.
    
    Ed Hott
    Prime Contractors DWT
    PRIMES::HOTT
    DTN: 429-3490                 
    


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

                                         Date:      23-Feb-1989 02:10pm EDT
                                         From:      CAROLYN SOMERVILLE @DCO 
                                                    SOMERVILLE.C AT A1 at MAMTS7 at DCO 
                                         Dept:      PRIMES SALES; DCO/212-B
                                         Tel No:    341-3142

TO:  ED HOTT @DCO


Subject: TCP/IP


Just a quick message to let you know that Oracle Complex Systems,
the systems integrator/prime contractor company recently formed
by Oracle Software, has a tremendous interest in TCP/IP and would
be greatly disappointed if it were not used in conjunction with
VMS DECwindows.

Regards,
Carolyn



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

                                         Date:      21-Feb-1989 12:53pm EDT
                                         From:      KEN FLOYD @DCO 
                                                    FLOYD.KEN AT A1 at MAMTS7 at DCO 
                                         Dept:      SALES
                                         Tel No:    341-2778

TO:  ED HOTT @DCA


Subject: DECwindows and TCP/IP


Ed,
My customer at Westinghouse will definitely want to see TCP/IP support 
in VMS DECwindows. In fact, the development system will have to have 
this communication option in order to suuport the target systems. 
Without this option, Digital will not be considered.
Regards,
Ken



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

                                         Date:      20-Feb-1989 04:28pm EDT
                                         From:      DAWN PLACEK @VFO 
                                                    PLACEK.DAWN AT A1 at MAMTS6 at DCO 
                                         Dept:      SALES
                                         Tel No:    439-5474

TO:  ED HOTT @DCO


Subject: VMS DECWINDOWS - TCP/IP FEEDBACK


ED:

I SPOKE WITH DR. STEVE BARRY, SENIOR TECHNOLOGIST FROM TRW, TODAY
REGARDING THE INPUT THAT YOU NEEDED REGARDING TCP/IP SUPPORT
WITHIN VMS DECWINDOWS.

STEVE'S ANSWER WAS A VERY EMPHATIC YES!  HE VIEWS TCP/IP SUPPORT
AS BEING CRITICAL FOR THEM TO IMPLEMENT THEIR WORKSTATION 
STRATEGIES.

HE INDICATED THAT HE VIEWS DECWINDOWS AS A SUPERSET OF X-WINDOWS
AND THAT DEC HAS DONE A GOOD JOB WITH THE PRODUCT.  HE IS NOT
HAPPY WITH DEC'S DECISION TO NOT INCLUDE THE TCP/IP SUPPORT.
HE INDICATED THAT THEY HAVE TO "PLUG AND PLAY WITH THE MASSES
REGARDLESS OF THE WORKSTATION THAT TRW IS SUPPLYING." WHILE TRW 
OFTEN PROPOSES DEC EQUIPMENT, IT NEVER STANDS ALONE.  TRW MUST 
BE ABLE TO INTEGRATE THEM WITH EXISTING SUNS, HP'S, ETC.

I HOPE THIS INPUT IS HELPFUL.  PLEASE LET ME KNOW IF YOU NEED 
ANYTHING ELSE.

REGARDS,
DAWN




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

                                         Date:      14-Feb-1989 01:27pm EDT
                                         From:      CLARE SKARDA @VFO 
                                                    SKARDA.CLARE 
                                         Dept:      SALES
                                         Tel No:    439-5473

TO:  ED HOTT @DCO                         ( HOTT.ED )


Subject: RE: VMS DECwindows Engineering needs some direction from us.

Ed,

Before I give my example, I have a question.  The example for a TCP/IP 
requirement you gave mentioned an RFP out of NSWC.  Is this real? If 
so, which NSWC location please.

My customer, Grumman Data Systems, needs TCP/IP from VMS DECwindows
because they are currently developing their applications in a 
multivendor, heterogeneous environment (all UNIX machines) and TCP/IP 
is the standard under UNIX.  Grumman's customers include the U.S. Air 
Force, Navy, Marines, and other government Agencies.  Grumman's 
opinion is that Digital is touting an open desktop environment, but 
we are not truly allowing our customers to use the potential here.  
Must they obtain DECnet capability for all third party platforms in 
their network?!  They would sooner forego the purchase of VMS systems.

Regards,
Clare



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

                                         Date:      14-Feb-1989 12:28pm EDT
                                         From:      DENNIS JOSEPH @DCA 
                                                    JOSEPH.DENNIS 
                                         Dept:      SALES
                                         Tel No:    429-9591

TO:  ED HOTT @DCO                         ( HOTT.ED )


Subject: RE: VMS DECwindows Engineering needs some direction from us.

ED,
THE MAJORITY OF THE RFP'S REQUIRE TCP/IP AND MY CUSTOMER NEEDS TO HAVE
DEC WINDOWS/TCP/IP SUPPORT. THEY ARE CURRENTLY DEVELOPING A C3I WORKSTATION
BASED ON OUR WINDOWS.
PLEASE HELP!
DENNIS

    

    I'd be very surprised if the relevan Product managers take their inputs
    from this conference. Have they contacted DECWindows Product Management
    directly?
    
    Andy

>
>    I'd be very surprised if the relevan Product managers take their inputs
>    from this conference. Have they contacted DECWindows Product Management
>    directly?
>    
>    Andy


  Andy,

 Okay, you've got him. However it also seems perfectly obvious that a few
very influential folks read this conference. It's also quite clear that 
there is a major requirement. Third the SS resource probably does'nt know
how to accomplish the contact or who to contact. Also it's an absolute
necessity that this capability be provided BEFORE the next major release.
I will send him the form that all of the VMS partners got for inputs,
hopefully that will be a start. I really believe we need to get off the 
horn and at least commit to this internally first. This is one desparately
important issue where if it's being discussed, or is being done, we should
let the field know NOW. I can't vouch for the European market, but in the
states this is or will KILL us, and I don't mean a black eye.


	Sorry for a flame,

		Mike Weaver

    Mike,
    
    	 I'm merely trying to help. No ulterior motives should be read into
    my note, I merely wished to point out that this ain't necessarily the
    most efficient way of communicating with with the relevant people.
    
    "Getting him" wasn't on my agenda.
    
    Andy

Could someone back in Spitbrook *pretty please with a free_dinner_and_tour_ 
of_SF_next_time_you_visit_out_here on top* get *SOMEONE* in VMS product 
management to "make a ruling" on this?

My understanding was that the next version of DECwindows was to finish up 
all the non-commits from V1.0.  Wasn't this on the list?  Does this mean 
that our happy VMS customers can continue to be happy VMS customers, or do 
we have to get them to move to ULTRIX?  We really need to know.

I'd be happy to go talk to Paul or Steve, but my office is alot further from 
them than my cubicle used to be(by about 3,000 miles).

This offer is valid for any kind soul who can get an answer to this critical 
issue.

g.

    
    There are no decisions.  There is only "a growing concensus inferred
    from an iterative dialog involving many individual and collective
    organisms seeking to form a working understanding ... blahblahblah."

Okie dokie.  No answer is an answer for the more antsy customers.

Will tell our VMS workstation customers that if they want to talk to their
Suns that they will have to run ULTRIX.  Will also try to find the method 
for DE-certing workstation sales from VMS to ULTRIX and post it here for the 
other field people who will need it.  ;->  Will also make sure that SSB 
knows how to report this, so all of Spitbrook sees it on the report on 
revenues.  I'm sure that since Heffner is now OS/SB, he would be more than 
happy to take the revenue back from Kurt.  Will also post the customers taking 
this approach or going to the competition because of this lack.

Maybe a few major customers doing this and a couple monthly revenue reports 
with debits from VMS for credits to ULTRIX will help the political process
along abit. 

g.

Would you please, for heaven's sake, talk to the DECwindows
product manager before doing things like reducing forecasts
and telling customers to undertake major conversion efforts!?
A notes file is NOT the right place to use as the sole
source for input on important decisions.  Not everything
can be said in a notes file.  Not everything implied in
a notes file is true.

Burns

    RE: .64
    
    Gail, deciding when to support TCP/IP is _not_ a "political process"
    but rather a question of engineering tradeoffs. The work involved 
    isn't trivial, and neither are the items that would have to be
    deferred to get this into the next version. 
    
    Questions like this should be addressed through the phase review 
    process or discussions with product and engineering management and 
    not through a notes conference. Sure, notes files are a good vehicle
    for feedback, but I hope the company isn't relying on them to drive
    product direction.

Clearly the the support of TCP/IP transport for DECwindows is a major issue, not
only internally, but with our customers.  I don't think that anyone is asking
for anything unreasonable, or or making threats.

Some important customers have one of two problems:
	1. they need TCP/IP support on all platforms today to do their business
	2. they have a clear need for TCP/IP support in the future
Few customers will think it unreasonable if DEC makes one of the following
statements:
	1. we will definitely provide support for this in the future, but
	   we have not been able to work out the details in order to announce
	   availability
	2. we are very concerned about the interoperability issues and are
	   unwilling to commit to support until we can specific the exact level
	   of support, but we do recognize the requirement
	3. we are unwilling to commit to support due to issues of
	   interoperability, but we do recognize that this issue will come up
	   with other protocols; therefore, we will provide a mechanism for
	   users, with the help of software services, to provide user written
	   transport support.  We are currently in the process of changing
	   the current interface to make this feasible.
What is unacceptable to customers are either of the following responses:
	1. We won't meet this requirement because <reason>.
	2. No comment.

A recent memo from VMS DECwindows product management announcing availability of
the Phase 0 documents lists TCP/IP support as a "critical element of the next
DECwindows functional release."  Although this is not (yet) a commitment that
it will really happen, I think we can assume that the issue is being taken very,
very seriously.

--PSW

    Re. .60
    
    Europe has given its inputs - TO PRODUCT MANAGEMENT.
    
    It is an emphatic yes, we want it. Any other information product
    management requests to support the work/decision process they get
    when they ask.
    
    Send your requirements and contributions to the right address, save
    your flames and heartBurns...;^)
    
    David

    I am a sales support person for the NWD.  We have observed a strong
    trend toward TCP/IP at Universities, Manufacturing and Government
    customers.  Indeed it is worse than mentioned above; that the customer
    is not just going to Ultrix but rather completely away from DEC to
    other Unix / X vendors.  We need to all drop the bigotted attitude
    against TCP and show that we can and will participate in these network
    environments.  Otherwise we will hasten the retreat of VMS and wound
    Ultrix efforts.
    
    						Mike Prezbindowski
    						(206) 637-4247
    

    I beleive that there is a misaprehension existing about the required
    support needed to provide a TCP protocol with VMS.  None or very little
    is required.  All other vendors I have dealt with do not guarrantee
    their implementation of TCP will work with any other vendors
    implementation - PERIOD!!!  We cannot expect to do any better.  If this
    is all that is keeping a standard TCP protocol from VMS then PLEASE do
    not try to support it as we do DECnet, ( A fine and nifty protocol).
    
    						Mike Prezbindowski
    						NWD Sales Support

    re .-1
    
    So if a "VMS TCP/IP" only has to talk to "VMS TCP/IP", what 
    does it matter whether it's TCP/IP or not?   Seems that any old
    proprietary protocol would do.
    

    
    RE: .72
    
    >So if a "VMS TCP/IP" only has to talk to "VMS TCP/IP", what
    >does it matter whether it's TCP/IP or not?  Seems that any old
    >proprietary protocol would do.
    
    Looks like you're missing the thread of this discussion.
    
    Most have accepted the fact that VMS cannot live on an island
    by itself.  It has to talk to the rest of the non-Digital world
    of *other* protocols in the X11 environment.
    
    Kris...

    re .73

    Read .72: 

>I beleive [sic] that there is a misaprehension [sic] existing about the required
>support needed to provide a TCP protocol with VMS.  None or very little
>is required.  All other vendors I have dealt with do not guarrantee [sic]
>their implementation of TCP will work with any other vendors
>implementation - PERIOD!!!  We cannot expect to do any better.  

    If we follow this approach, we'd be saying "here it is, but we don't
    guarantee it to work with any other vendor's equipment. So it's only
    guaranteed DEC-to-DEC." If that were there case, there would be no
    point, since we have DECnet to go DEC-to-DEC. The point of supplying
    TCP/IP as a transport is to allow intervendor interoperability.
    Providing something solely for intervendor operation, AND NOT
    SUPPORTING IT FOR INTERVENDOR OPERATION, would be silly indeed.

    
    RE: .74
    
    Sorry if my comments sounded like support was not an important
    issue.  Just that long product gestatation periods normally play
    into the hands of our competition.
    
    Kris..

The important thing to keep in mind is that one cannot guarantee that
our TCP/IP implementation will work with every other TCP/IP implementation.
It is possible to say with some confidence that it should work with any
correct implementation, and there should be some interoperability with other
vendors, as well as with Ultrix.

TCP/IP is critical to our future; we should be doing the best we can to
come out quality TCP/IP products.

	- Win

1. Is there any way (perhaps unsupported) to use a SLIP link with
DECWindows? 

2. Any ideas on how a 9600 BPS or say a Trailblaizer PEP link would
work in terms of performance. 

3. If no such thing exists, would there be any relatively easy way to
make such a setup shy of writing a new DW transport? 

>1. Is there any way (perhaps unsupported) to use a SLIP link with
>DECWindows? 

Could you tell us more about SLIP?  I've not heard of this one before.

> Could you tell us more about SLIP?  I've not heard of this one before.

Yes, it stands for Serial Line IP and is a way of sneaking IP traffic
over a serial line instead of a LAN.  This is a handy way of accessing
a TCP/IP host where no LAN connection is available, say using high
speed modems (>= 9600 BPS). 

Well, if you can fool UCX into using the serial line, then you can use
the built-in DECwindows TCP/IP transport layer.  Otherwise, you're out
of luck, unless you want to write your own DECwindows transport layer.

    
    SLIP is a hack....and does not work too well with X.
    Any speed below 19.2kb is sluggish.  I spoke to the
    developer of SLIP at last year's XHIBITION'89....
    he was amused at the idea that SLIP could be used
    with X.  He suggested that vendors design a new serial
    line IP/OSI protocol to cater to X.
    
    Kris...

    
    I'm looking for a document which describes how the transport mechanism
    is set up in VMS and DECwindows.  I've got an application which needs
    to talk both DECNET and TCP/IP and I'm just looking around at what has
    already been done...
    
    regards,
    
    steve

The VMS DECwindows Transport Manual (Order Number AA-PABWA-TE) describes
the VMS DECwindows transport layer.

Generally speaking, the transport does DECnet $QIOs to talk to DECnet,
and UCX $QIOs to talk to UCX's version of TCP/IP.  The common transport
layer provides a set of generalized input/output routines that dispatch
to corresponding routines in the network-specific transport layer.

The model is tuned for X.  I'm not sure I'd recommend the VMS DECwindows
transport model for other applications.  I personally prefer the RMS model
of $PUTs and $GETs for general data transfer.