Conference bulova::decw_jan-89_to_nov-90

Ed Santiago, Workstations Systems Engineering

Desperately waiting for code that will work on a Firefox. As soon as
that happens, I will use it to launch all sorts of clients, mostly
xterms, from our Ultrix machines. Also, if SLIP ever gets to work,
I can try to use it to run clients from my Fox to my home machine.

From what I've seen of it working, I think it's great and an absolute
must for a real integrated environment.

    Jeff McLeman, Workstations East. 
    
    Been using it between our ULTRIX system and my 3100. Works like a
    charm.
    

    Scott Robinson, LMSB Engineering

    I use it to connect a UWS workstation with ULTRIX V3.0 on
    several 8800s. Had no problems with TCP transport on DECWindows...

    Do have some problems due to DECnet network instability when
    using VMS DECwindows. If the local router changes, the logical
    links appear to drop causing my calendar and DECterm windows to
    go away. TCP transport doesn't exhibit this behavior.
    

    James McCartney - DECforms Development
    
    Use the transport  to  talk to our PMAX systems, also to our Ultrix/VAX
    machine. Have had some problems, but the code appears to be usable and
    stable. A fully funded and supported transport effort is badly needed.
    
    Now if we could only get an "rlogin" or "SET HOST/TCP"....
    
    James
    

from VMS vs2000 to VMS 8550, but now only use it intermitently to a VMS 6220
until new system configuration is stablized and UCX is running on both boot
servers.  I found that TCP/IP was quite stable with connections up for days
and it was much better at dealing with cluster transitions and network problems
than DECnet.  In the past week using DECnet, I'd say that one or more DECnet
connection breaks every day for no reason that I can tell; it usually happens
while workstation is paused.

I also use it occasionally between an Ultrix vs3500 and VMS 8550 and VMS vs2000
with no problems related to transport.  (The Ultrix server isn't quite up to
snuff when running some decwindow apps.)

    I've just started using the TCP/IP transport between a VMS GPX and a
    PMAX.  However,  I've only been able to get the GPX to be the client
    and not the server.  What should I be using as the authorized client
    under the Security selection under the SM.  I've tried:
    
    	- nodename::*
    	- *::*
    	- nodename:0 -> does not work
    	- * -> gives 0::*
    	- nodename -> gives 0::nodename
    
    It seems to work fine with the GPX acting as the client.
    
    Will continue to play.....
    
    mike

You might have to hack Xdefaults yourself - the Session Manager won't let
you enter nodenames over 6 chars long. Apart from that, node::* works
fine for me on my VMS workstation.

BTW Be sure to increment sm.num_hosts too. Dunno if it makes a difference
but it's probably a good idea.

    >>> the Session Manager won't let you enter nodenames over 6 chars long
    
    I assume that's the VMS Session Manager... if so, the character
    limitation still seems rather parochial, especially considering
    that a version of DECnet in the not-so-distant future will allow
    longer names.  Should someone submit a bug report on this?
    Or is the code already wired for recognizing the DECnet version?
    
    John

    
    *::* will allow access from anywhere.  Did you apply it?  Did you
    restart the server after installing tcp/ip?  Did you try a command such
    as "mc ucx$ucp sho dev" to see if the server is listening at port 6000?
    
    						monty

re .8

Monty,

Ultrix seems to dislike *::* when appended to the host access list in 
security

hostname::* works fine though.

Kris..

	Hopefully, this won't generate too many flames.  This subject
seems to ignite the passions of some noters.

	I've tried to locate the kit info for the VMS TCP transport
stuff but can't find it.  I did a directory and checked keywords but
there is either no clear subject line or I didn't search thoroughly
enough.

	Anyway, I'd be happy to provide feedback on my experiences with
it if someone would be kind enough to point me at the kit.

	Anyway, we have 3 PMAX systems with no DECnet (and they're not
likely to get it either) which need to be able to access certain DECwindows
clients on VMS.

	You can either reply here or send mail if you prefer.

Thanks for any help.

    
    No flames.  The pointers and instructions disappear from the notesfile
    from time to time.  So here's a repost with updated information.
    
    					monty

    
				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 (Smurf::) 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.

Out of curiosity, why is there a problem getting DECnet for the PMAXes?

	paul

    
    	Just one other curiosity question...
    
    	If one would have an X11 baseline 3, and a XUI built for a SUN,
    	one should except to see a rather transparent usage of the
    	SUN to the DEC workstation, true?
    
    	So... data flow should look like this:
    
    		DECwindows --> TCPIP Transport --> UCX --> SUN XUI
    
    	This will have to be tried out... tomorrow...
    
    		Thanks for the ideas and methods...
    
    	

	First of all, let me point out that there is NO PROBLEM getting DECnet
fo PMAXes.  Lots of folks have it and it works great from what I hear.  MY
problem is DIS.  We don't have any more node numbers in our area.  The fact
that only about 50% of the assigned nodes are reachable makes me wonder just
how many 'virtual systems' are registered.  That's another topic though.

	Anyway, thanks for the pointer.  I followed the instructions, copied
the file, set prot, modified startup files, restarted DECwindows.  I then
changed my login file on our cluster so that my set display looks like this:

		set display/create/node=lensmn/transport=tcpip

	LENSMN is an Ultrix workstation on my desk.  UCX is installed and
works fine (a large portion of LENSMN's filesystem is mounted on the same
cluster via NFS).  When I try to run an application on the cluster and export
the window, it says 'Can't open display' and 'Fatal toolkit error'.  We're
running V51 of VMS on the cluster.  I checked, using INSTALL, to make sure
that the TCP/IP transport image had actually been installed by the restart
and it has.

	What do I check next?

    
    re .15:  This is what will *eventually* work.  Don't bother trying to
    run a big-endian client against a V1.0 VMS DECwindows server.  It just
    isn't worth trying.  Using SUN servers or clients from the 386i may
    work.
    
    re .16:  Security is most likely the problem.  There is no remote
    username with tcp/ip.  Use either '*' or '?' as the username in the
    security entry.
    
    						m

	I'm not running DECwindows so I specify all my security using
xhost.  I have added the cluster nodes to the list of nodes in xhost.
Using xhost, I've been able to allow DECnet and TCP systems to open
windows on my WS.

	When you specify the node in xhost, there is never a username.
You distinguish between DECnet and TCP hosts by including colons with  
the node name.  

	Is anybody doing this with an Ultrix WS NOT running DECwindows?

    Can you loop/ping LENSMN from the VMS system?

	Re .-2

	Yes, LENSMN and the cluster see each other.  As I said, part of
	LENSMN's file system is mounted on the cluster using NFS and works
	fine.

	Re .-1

	Turn off security?  You mean allow ALL nodes to access the system? 
	Hadn't thought of this but will give it a try.

    
    	Something new about using VMS 5.2/DECwindows, UCX 1.1, and 
    	the UNSUPPORTED TCPIP transport to a SUN/XUI server.
    
    	Able to send displays to the SUN, at least most... I haven't
    	been able to actually start a login sessions from a VMS
    	host on the SUN.
    
    	The MIT Xserver isn't quick... in fact, you can overload it
    	very easily...
    
    	The biggest problem, trying to send an X display from a SUN
    	to the DECwindows/workstation.
    
    		o  First you must open the door "security wise"
    		   to give the IP nodename and a "*" for username.
    
    		o  Check to make sure that the UCX is listening:
    
    			( socket 1600)
    
    		...Now comes the fun....
    
    		Execute an image on the SUN that will send output to
    		the DEC/workstation.
    
    		On the SUN side, you'll get an error message that the
    		pipe is broken...
    
    		Now look on the DECwindows screen, the display manager
    		is gone.  If you press a key or move the mouse the
    		screen goes dark...
    
    	Anybody else....
    		

RE: .22

Endian problems, perhaps?  Suns are big-endian machines.  The VMS DECwindows
server doesn't do byte swapping properly until DECwindows V2 (which isn't
part of VMS V5.2).

--PSW

The PMAX and the Sun 3/60 are of different endian types..

I have performed a few experiments between a Sun 3/60 (MIT X11R3) and
the PMAX ......and TCP/IP seems to works fine.

Interesting to find out that I could interoporate from the Sun to the
PMAX using Sun's hack of DECnet (Sunlink DNI..)

DECwindows calendar is one of the few DECwindows clients that break. (font
problems).

Kris..

    The PMAX and the Sun 3/60 are of different endian types..

I have performed a few experiments between a Sun 3/60 (MIT X11R3) and
the PMAX ......and TCP/IP seems to works fine.

	Oh well, between MV-II or MV-III with a DEQNA or DELQA
    	with VMS 5.1-1 or 5.2 the DEC systems can create
    	displays and send them to a SUN or another VMS via
    	TCP/IP protocols.
    
    	But, SUN to DEC does bad things to the DECwindow server.
    
    	Today things went interesting, can't transmit an X window
    	via TCPIP between VAXen in the same cluster, however
    	the SUN still send to the VAX.  Testing UCX works
    	using FTP to check conductivity.. sigh.
    
    	Paul, will DECwindows V2 be compatible with the current
    	Field Test Release of UCX?
    
Interesting to find out that I could interoporate from the Sun to the
PMAX using Sun's hack of DECnet (Sunlink DNI..)

	Nope...  DNI was a terrible implementation of DECnet,
    	my customer won't even consider it in a production
    	environment.
    
DECwindows calendar is one of the few DECwindows clients that break. (font
problems).

    	You should see what the DIGITAL logo looks like or the
    	fonts for the session manager.
    

    Al....

RE -1

>	Nope...  DNI was a terrible implementation of DECnet,
>    	my customer won't even consider it in a production
>    	environment.

AGREED!

I was just commenting on ENDIANS!  Read my note again carefully...

Kris...
    

re .25:

In order for the DECwindows transport to accept TCP/IP protocol, TCP/IP 
must be running before DECwindows is started.  You must modify the startup
such that DECwindows starts *AFTER* UCX is started or, after UCX is 
started, you can restart DECwindows. 

UCX between machines will work, even if DECwindows won't.

V2 of DECwindows supports Reverse Byte Sex clients.

						.dave.