Conference bulova::decw_jan-89_to_nov-90

Are you sure you have the SSB version of the documentation?

The V5.3 installation guide has a big new chapter on Starting and
Customizing VMS DECwindows Software, which has a section on how to
set up DECwindows for use with TCP/IP.

Also, the VMS DECwindows User's Guide has an extensively revised
chapter on Running Applications Across the Network, which includes
information on how to use DECwindows over TCP/IP.

The two usual stumbling blocks are:

1) not creating SYS$MANAGER:DECW$PRIVATE_SERVER_SETUP.COM
and
2) not specifying "*" as the username in the security menu.

    
    Peter:
    
    	Thanks for the reply, I must have missed it in the V5.3 IG, I
    don't have the DW UG in the Bookreader. I'll look closer
    tomorrow.
    
    Thanks again,
    Randy
    
    

    
    
    I got it working this morning, thanks. I got it working by giving
    the world access to the server screen. I had tried REMOTE_TCP,
    REMOTE_TCP: and * for the username. I ended up giving it an *
    for the nodename as well.
    
    Just got off the phone with the sales rep (who delivered) and the
    customers (Cray Research). They successfully made a connection from
    the Cray they have in Minn. back to the VS3100 and ran Xclock and
    also a Xterm on it. 
    
    So, thanks,
    Later,
    Randy
    
    

For TCP/IP, you must specify * as the user name, but you should be able
to specify the actual node name.  The common problem with TCP/IP node names
is that the TCP/IP node name isn't defined in UCX's database, so the server
has no way of converting the TCP/IP node number passed in the connection
to a TCP/IP node name that can be checked in the security menu.

    I'm assuming that you need OUR UCX product to get a TCP/IP that
    works with V2. Now our customers have to choose to have our UCX
    that lacks some utilities or have their Brand X TCP/IP, but not
    usable as the transport for DW ?
    
    The only way to let them use Brand X TCP/IP is to continue to use
    DECnet as the transport. Of course this pushes up the price of a
    DECstation, since DECnet is not bundled.
    
    Our competition will use this as another argument againest us.
    
    
    Bill Z.
    
    ( BILLZ::ZAHARCHUK )
    
    

    
    Re: .4
    
    I had NODE and NODE: in the Security database. I had NODE as
    defined in the UCX database as well. It was not until I gave 
    the node name as * was I able to get past the authorization
    failure when trying to run the remote application. I was using
    the TCP alias name vice the actual name. Maybe ?? 
    
    While I was on the phone with the customer trying to get it
    configured at their site, we had to use the UCX SET ROUTE
    command to get it to link up to the remote Cray in Minn.
    
    Thanks again,
    Randy
    
    
    
    

>    						...   I was using
>    the TCP alias name vice the actual name. Maybe ?? 

I'm sorry, I don't understand what you mean by this sentence.
What exactly do you have for your node name definition?

>    I'm assuming that you need OUR UCX product to get a TCP/IP that
>    works with V2. Now our customers have to choose to have our UCX
>    that lacks some utilities or have their Brand X TCP/IP, but not
>    usable as the transport for DW ?

This will not be true soon...

It is true that the TCP/IP transport interface that we ship with V2
only works with UCX.  However, we are publishing the transport interface
so that third-party vendors can write their own DECwindows transport
interface.  You should encourage your customers to contact their TCP/IP
vendor to find out the availability of the vendor's transport interface.

By the way, I'm interested in hearing what utilities the UCX product
lacks.  I understand UCX V1.2 adds a few more utilities, but I'm not
familiar enough with the TCP/IP market to know what's missing or not.

    
    Re: .7
    
    When I added the remote DS3100 into my UCX host database, I used
    the following command:
    
    $ UCX SET HOST "mmike.dco.dec.com"/address=16.67.32.58/ALIAS="mmike"
    
    Then I added both MMIKE and MMIKE: to my DW security list with username
    as *.
    
    That's what I meant by the Alias name.
    
    Later,
    Randy
    
    

    .5 should realize also that the well-known TCP/IP vendors were
    DECwindows field test sites, and have already had plenty of time to
    develop transports that work with their TCP/IP implementations.
    
    As an aside, UCX does not need to be licensed if it is only used as
    the DECwindows transport.

Re: .9

Thanks, Randy.  You have uncovered an oversight on our part.  When we
check for authorization, we check against the main host name, but not
against any of the alias names.  You will have to enter the full name
MMIKE.DCO.DEC.COM to the security list instead of the alias name.

Please QAR this problem in the V50 database on TRIFID so I'll remember
to try to fix this in a future version.

    RE: Missing UCX utilities...
    
    Ya got rlogin - that's one of the biggies.
    
    How about yp, bind, rwhod, fingerd, smtp/sendmail et. al... 
    All the standard daemons on U*ix systems.
    
    It would also be really neat to say:
    
    SET HOST/RLOGIN xyzzy.net
    
    James
    
    
    

Lou Yelgin has given me permission to post this memo in this notes
file.  Although the deadlines for the Phase 0 requirements have passed,
I'm sure you can still post questions about the future availability
of particular TCP/IP utilities in the SMURF::CONNECTION notes file.
Hit KP7 to add this conference to your note book.

Peter

+---------------+
| d i g i t a l |   I n t e r o f f i c e   M e m o r a n d u m
+---------------+
 
 
To: Distribution                        Date:  September 5, 1989
                                        From:  Lou Yelgin
                	                Dept:  OSCR Product Management
        	                        Ext.:  DTN 381-0523 Loc.: ZKO3-3/V06
	                                Net.:  xirtlu::yelgin
 
 
Subject: UCX Phase 0 Opening

The purpose of this memo is to open Phase 0 for V1.4 and V2.0 of the
VMS/ULTRIX Connection (UCX).

The VMS/ULTRIX Connection (UCX) is a software product that promotes resource
sharing between VAX/VMS servers and UNIX (TM) worksystems. The product
provides a bridge between VMS servers and UNIX clients without
modifying the syntax or semantics of either operating system.

UCX V1.2 is currently in field test and will FCS at the end of November
1989. Functionality includes Telnet, rlogin server and support for the
VAX C socket interface.

UCX V1.4
========

Planned functionality for UCX V1.4 is the implementation of remote procedure
calls (RPC) via V1.5 of Apollo's NCS (Network Computing System). This
technology allows an application to be distributed across nodes in
a network. The result is increased performance as programs can access all 
available compute cycle in a network and run processes in parallel on a 
number of machines. 

Public documents for UCX V1.4 will be available for review in October 
with a Phase 0 exit in November. The FCS date is May of 1990.

The deadline for submissions for UCX V1.4 is October 13, 1989. 

UCX V2.0
========

UCX V2.0 is a major functional release of the product. Planned functionality
includes the following:

	o SMTP (Simple Mail Transfer Protocol)
	o inetd
	o Diskless booting and remote installation
	o rlogin client
	o NFS client on VMS
	o VMS Integration of TCP/IP functionality

Other functionality under consideration includes:

	o NFS lock manager
	o Network Management (SNMP, CMIP)
	o RV disk support
	o Authentication (KERBEROS)
	o $IPC integration
	o X.25 functionality
	o Cray driver
	o Design and implement security enhancements 
	o Portal/WAN routing
	o mcc access module
	o DECwindow-based system manager interface
	o Serial Line IP (SLIP)
	o 802.3 support
	o Load Balancing for NFS services
	    (Cluster-load balancing at the application level)

Public documents for UCX V2.0 will be available for review in November with
a Phase 0 exit in December.

The deadline for submissions for UCX V2.0 is November 17, 1989. 

Submitting Requirements
=======================

Product management is developing the requirements document for UCX V1.4 and
UCX V2.0 from inputs received via the attached Input Form and directly 
through the following VAX Notes conference:

    	SMURF::CONNECTION

Please contribute by sending the attached Input Form to xirtlu::yelgin, 
or by using SMURF::CONNECTION VAX NOTES conference.

Requirements form attached. 

UNIX (TM) is a trademark of AT&T Bell Laboratories



                VMS/ULTRIX Connection Requirements Input Form
                =============================================

		   Return to xirtlu::yelgin 



     1.  Submittor:

     2.  Designated Responsible Individual:
         DTN:
         Node:
         Loc/Mail Stop:
         Position:

     3.  Engineering or Marketing Group Supporting Requirements Request:
         Include name and brief description of group.

     4.  Abstract:
         Include brief, single-paragraph, description of each requirement.

     5.  Description:
         Include detailed description of each requirement and an indication of
         what you hope to achieve.  

     6.  Schedule:
         Note any schedule concerns for dependent products.
         Specification available (as much detail as is appropriate):
         Proto Available:
         Test Schedule:
         Planned FCS:

     7.  Benefit:
         Description of benefit, including substantiating data.

     8.  Impact of Not Meeting Request:
         Describe impact to DEC if request is turned down.  Please  explain
         this in terms of lost opportunities and markets.

     9.  Justification:
         Include here any other reasons for this request.

    10.  Rating:
         To be provided by Designated Responsible Individual.

         Ratings can be numerical ranking (1, 2, 3, and so  on)  or  evenly
         spread  across  total  list (as top 25%, middle 50%, and low 25%).
         Please indicate  whether  requirement   is   desirable,
         required,  or  critical.   If  more than one requirement is given,
         please state the relative priority of each.

    11.  Known Issues:
         Include statement of risks to either schedule or content.

    12.  Support Documents:
         Identify any documents that add detail to the request.

    Hello,
    
    I have been asked to set up a demo for one of our big customers. The
    demo is to show how DECwindows works across the network. Not a problem
    I hear you cry, but, the hardware that has been requested is as
    follows:-
    
    VS3100 running VMS
    DS3100         Ultrix
    DECstation PC of some kind running PC DECwindows
    and the cream on the cake
    a Silicon Graphics workstation (system V and X11 )
    
    The customer would like to see an application running across all
    platforms at the same time ( something like swimmer from the district
    demo ).
    
    I know I can do it across all of our stuff using DECnet. I presume
    inorder to integrate the SG workstation I need to use 5.3 VMS and UCX
    so that we use TCP/IP as the transport across all but the PC. Here are
    my questions:
    
    1	can I intergrate a SG workstation 
    2	has any of you tried doing this
    3 	if it is possable how do I handle the fact that the SG workstation
    must use TCP/IP (I assume ) and the PC must use DECnet
    
    Thanks in anticipation
    
    Ken De Carlo (7844 3474 )
    SED750::DECARLO KEN DECARLO @ESO
     

Assuming that you want to run the application itself on VMS, then
it is quite possible for the same application to use DECnet to display
to one workstation, and TCP/IP to display to another workstation.

Here is an example.  Assume that "pcnode" is a DECnet node, and
"ultrix" is an INTERnet node that you can access through UCX.

	$ SET DISPLAY/CREATE/NODE=pcnode/TRANSPORT=DECNET WS1
	$ SET DISPLAY/CREATE/NODE=ultrix/TRANSPORT=TCPIP WS2

Then in your program, use

	display1 = XOpenDisplay("WS1");
	display2 = XOpenDisplay("WS2");

VMS will translate the logical names WS1 and WS2 to the appropriate
displays, and use the protocol you specified.

I haven't tried this with an SG workstation, but I know of no
reason why it shouldn't work in theory.

    Thanks for the info.  I was having the same problem and couldn't make
    sense of the docs (or preceding notes).
    
    My question is:  Is this the only way to specify a TCP/IP "display"
    	in the VMS world now and in the future??  Or are we supporting/
    	considering supporting the DISPLAY semantics available under
    	Unix/Ultrix (ex. WS1:0 is TCP/IP; WS::0 is Decnet)?  
    
    

The SET DISPLAY command is the only way you can specify TCP/IP as the
DECwindows transport on VMS.  I know of no plans to support the single
colon syntax in XOpenDisplay to specify TCP/IP as the transport.  Do you
think it important that we should?  If you have good reasons why we should
support it, we will certainly consider it!

    The only reason I can think of to support the single colon syntax for 
    TCP/IP as a transport is consistency with other (non-VMS) versions of
    X.  Also we do support the double colon syntax (WS::0) for Decnet 
    which is particularly useful in programming (since a SET DISPLAY is
    not required) and you can still open the display.  
    
    However, is this worth pushing??  I'm not sure.  What happens when
    other transports are available?  Do we have to make more transport-
    specific naming conventions?  (And should we?)  What are the X people
    doing about this??  
    
    Obviously I don't have the answers, but I am good at the question
    parts.  I am curious what the X community is considering as more
    transports become available.  And I do think consistency is important.
    

    Ok....
    
    I have VS3100 running VMS5.3/DECWv2.0/UCX1.2
    
    I read the doc regarding TCP/IP support in VMS5.3 IG Chapter 10.
    I followed the instructions Transport = "TCPIP"
    
    I can open a window from VMS to the RISC DS3100 via TCPIP
    set display/create/node=unxone/transp=tcpip
    
    but... I can't go the other way from RISC with
    setenv DISPLAY vaxone:0.0
    
    I have set security Session Manager with node = * user = *
    and transport = tcpip.
    
    Any ideas ???
    
    I used UCX SET HOST "UNXONE" /ADDRESS=128.1.0.1 /ALIAS="unxone"
    and tried various combinations in the security session manager section
    ie. node unxone:, unxone,   user root, *   transport = tcpip.
    
    Any help is appreciated....
    
    Regards,
    
    Tony

Look in SYS$MANAGER:DECW$SERVER_0_ERROR.LOG and see if you have any
failed connections logged.

Try "pinging" the VMS node from the Ultrix node.  Modifying the UCX
database won't affect anything, as it is the Ultrix database that has
to be correct when going from Ultrix to VMS.

To verify that the VMS server can correctly accept TCP/IP connections,
$ SET DISPLAY/CREATE/NODE="vaxone"/TRANSPORT=TCPIP
and then run some application.

One of these tips should locate the problem.

    Hi,
    
    I have exactly the same problem as .19.
    
    We are setting up a crucial demo to a major customer which we hope to
    give on Friday 23rd Feb!
    This is a potential SUN knockout.
    
    We have VS3100 VMS v5.3-1
                   UCX v1.2
            DS3100 UWS V2.1
    ALSO we are hooking SUN workstation (arrives this afternoon)
    AND a VT1000 terminal.
    
    I've had a look on DECW$SERVER_0_ERROR.LOG and it seems full of the
    following pair of messages:
    
    21 Feb 1990 12:34:05   Connection 2cfc00 is accepted by Txport
    21 Feb 1990 12:35:01   Connection 2cfc00 is closed by Txport
    (status=20e4)
    
 What is this telling Me?
    
    I have 'pinged' to the VMS system - no problem.
    
    Have used set disp/cre/node='ultrix'/trans-tcpip and run up vue$master
    onto the RISC ultrix system - no problem.
    
    no problems using TELNET to VMS.
    
    I can do everything but use TCP/IP to transport Decwindows to a VMS
    system.
    
    I am trying to use 
    setenv DISPLAY vms-node:0.0 
    but when i start up the application it reports an X-toolkit error
    (cannot open Display).
    
    However,  setenv DISPLAY tcp-ip-addr:0.0
    works ok to VT1000!
    
    CAn anyone help/point me in the right direction??
    
    Regards
    
    
    Malcolm
    
    
    
    
    
    

    re .20 and .21
    
    Update......
    
    I can ping vaxone from unxone......
    I looked at the log files... same messages as note .21
    I can't tcpip to myself on vaxone.
    
    SET DISPLAY/CREATE/NODE=VAXONE/TRANSPORT=TCPIP
    
    What next ????
    I'm stuck......
    
    Window manager security screen Node = *,  User=*,  Transport=tcpip
    
    Help me I'm melting.....
    
    Regards,
    
    Tony
    

The "Connection accepted" messages and the corresponding disconnect messages
are normal.  If you had messages like this:

5-FEB-1990 11:25:11.5 Invalid access from transport: DECNET
                                                node: HELTER
                                                user: FISHER
15-FEB-1990 11:25:11.5 Invalid access from transport: DECNET
                                                node: HELTER
                                                user: FISHER

that would indicate that the connection request from the client was
reaching the server, but that the server was rejecting it because security
was not set up right.

Try looking at the beginning of the log file.  It should look like this:

15-FEB-1990 11:21:42.7 Hello, this is the X server
Dixmain address=13074
Now attach all known txport images
%DECW-I-ATTACHED, transport DECNET attached to its network
%DECW-I-ATTACHED, transport TCPIP attached to its network
in SetFontPath

If the line about TCP is not there, the server is not listening on TCP.  Look
in SYS$MANAGER:DECW$PRIVATE_SERVER_SETUP.COM.  If there is not a line which
says something like

$ decw$server_transports == "DECNET,LOCAL,TCPIP"

then TCP will not be enabled.  See SYS$MANAGER:DECW$PRIVATE_SERVER_SETUP.TEMPLATE
for more info.  Also in the DECWINDOWS Users' Guide (I think).

Burns

    Thanks,
    
    Working now.... Both ways. The problem was in
    DECW$PRIVATE_SERVER_SETUP
    
    Once I added the transport line regarding TCPIP everything worked fine.
    I do have a question though.
    
    When I first started looking at the TCPIP issue though, I found the
    transport line in the DECW$STARTUP.COM and assumed that I didn't need
    to do it again in DECW$PRIVATE_SERVER_SETUP.
    
    Why is this I guess ???
    
    Thanks for all of your help, My demo will now run great !!!
    
    Regards,
    
    Tony

DECW$STARTUP just installs the transport as a known image.  This is required for
either the server or the client to use it.

We did not want TCP to be enabled by default, since we don't believe the security
in TCP is as granular as in DECnet.  Thus, you have to explicitly define the
symbol.  In DECW$STARTSERVER, there is the following line:

$ decw$server_transports == "decnet,local''tcpip'"

Note that tcpip has single quotes around it.  This makes it a symbol that
gets translated.  Searching further, you find that the symbol is only defined
if a certain logical is defined.  Thus...the default is normally no TCP.

Burns

    Thanks, just wanted to know, that makes things much clearer.
    
    Regards,
    
    Tony 
    

    re .25
    
    a couple of questions just to clarify things.
    
    if i also want to use lat as a transport do I need to enclose it in
    quotes as per TCPIP. for example would the following be correct?
    
    $decw$server_transports == "decnet,local''tcpip'''lat"
    
    My other question is what kicks of DECW$PRIVATE_SERVER_SETUP.COM
    
    We have just installed VMS 5.3-1 to allow us to do the demo that I
    mentioned in .21, however we have no documentation and the demo is
    tomorrow. It turned out that we had no DECW$PRIVATE_server_setup.com
    set up so I have built one using the hints + tips mentiones elsewhere
    in this topic. However, now I have built it I cannot see waht actually
    runs it.
    
    Should I have an entry in DECW$startup.com to launch it?
    
    I would appreciate any and all help given. Please bear with me as I am
    an ULTRIX guy trying to put together what I know will be an excellent
    demo.
    
    Thanks
    
    Malcolm

    re .27
    
    Sorry, my first question is ambiguous. I am looking for format details
    for DECW$SERVER_TRANSPORTS in the DECW$STARTSSERVER.COM file.
    
    Sorry again
    
    Malcolm
    

    re .27 & .28
    
    I've managed to work it out!
    
    It works just fine now and accepts incomings from RISC DS3100 and a
    Sparcstation also.
    
    Thanks for the hints & tips
    
    Malcolm

1.  Don't modify DECW$STARTSERVER.COM at all.  We were describing the
    the internals to you to answer your particular questions, but I
    don't think we've made it clear that you should *never* have to
    modify that file to use TCP/IP or LAT with DECwindows.

2.  To add TCP/IP or LAT to the list of transports that the server
    will use, copy DECW$PRIVATE_SERVER_SETUP.TEMPLATE to 
    SYS$MANAGER:DECW$PRIVATE_SERVER_SETUP.COM, and edit that file.
    All the directions you need to modify the file to add TCP/IP
    and LAT as transports for DECwindows are in the file itself.
    The file itself gives correct examples of symbol definitions.

BTW, this may be out of date, but last I knew, we support lat only for
clients going out to a VT1000.  I don't believe we (actually the LAT driver)
yet supports incoming LAT connects to a workstation server.

If this is true, it is a bug that LAT is being mentioned in the .TEMPLATE file.


Burns

re: .27,.28,.30

Don't edit anything at all...just DEFINE/SYSTEM DECW$INSTALL_TCPIP "TRUE"
before starting DECwindows.  The /SYSTEM insures that the definition
will be around if the server is restarted.

LAT transport is started by default.  If you don't want it, define
DECW$IGNORE_LAT.

Cheers,
Mike

>Don't edit anything at all...just DEFINE/SYSTEM DECW$INSTALL_TCPIP "TRUE"
>before starting DECwindows.  The /SYSTEM insures that the definition
>will be around if the server is restarted.

This is not the supported method for installing TCP/IP support.  Please
use the supported method, which is SYS$MANAGER:DECW$PRIVATE_SERVER_SETUP.COM.
This is what we document in the VMS installation guide.  Thank you.

    The reason we want you to do it in the server config file is that in
    the future there may be multi-seat systems available, and you may wish
    to have different parameters set for each seat.  If you do the
    definition in PRIVATE_SERVER_SETUP, the logical gets stuck in the
    server private table.
    
    Note that the method in .34 requires editing SYSTARTUP or something!
    
    Burns