Conference bulova::decw_jan-89_to_nov-90

  Sounds like a host list problem...access to server not granted.  I'm a UNIX
moron so I can't help you there.

  I have seen other notes that discuss the connection name thing between VMS
and other-than-VMS :^)....

					-=> Jim <=-

The oddity mentioned above is with DECnet/Ultrix and what it puts in the
username field when it connects.  I don't think it is relavent here, although
I agree that the problem is probably host-list related.

What transport are you using?  TCPIP?  (I think Sun actually supports DECnet,
believe it or not).

Assuming TCPIP, make sure that the VMS node is known by name to the Sun node.
Then try (on the Sun node) 

		Xhost vmsname:0

If that does not work you need to fool around with Xhost a little harder and
see if you can specify *, for example.  I don't remember.

Burns

    re .2
    The transport is TCP/IP.  Also, they have been able to start up other
    clients like dxclock and dxcalc (or whatever the VMS equivilants are
    called).
    

Sorry...it's now beyond me.  All I know at this point is that DECterm sends
a different username in DECnet than most applications.  I think it sends the
actual username rather than the UIC.  I have no idea if it would do anything
differently with TCP or not.

Any dxterm/Sun Unix/TCP experts out there?

Burns

Re: .0

Message 2DBC002 is defined in sys$message:decw$terminalmsg.exe, and means
"Can't open display".

Apart from that, I'm not sure how to help.  This could very well be a bug in
DECterm. Other people have also reported having trouble directing DECterm
output to SUN servers over TCP/IP; see note 593 in HANNAH::DECW$DISK:[PUBLIC]
DECTERM (KP7 to select).

				-- Bob

Re: .5

>               -< Check the discussion in the DECTERM conference >-
>
>Apart from that, I'm not sure how to help.  This could very well be a bug in
>DECterm. Other people have also reported having trouble directing DECterm
>output to SUN servers over TCP/IP; see note 593 in HANNAH::DECW$DISK:[PUBLIC]
>DECTERM (KP7 to select).

See also note 603.* in the same conference.

-Mark

Running DECterm from a VMS system to a SUN X11 R3 server should work.

This was recently tested at Connectathon '90, where VMS clients were
run against many other vendor's X11 servers. Aside from problems with 
font-fallback, where DECwindows clients don't gracefully recover if 
the server doesn't have the fonts they need, almost everything worked.
The font-fallback problem is usually easy to work around adding a font 
alias file to the other vendor's server.

Here are the steps to take:

   1. From the VMS system, define the display path:

	$ set display /create /node="sunsys" /transport=tcpip

      Note that the nodename must be contained in quotes to be
      handled in a case-sensitive manner. 

   2. Run a test program that doesn't ask for any fonts to see if
      everything is working so far. I like to use MIT's ico, since
      it has better error reporting on display connection failures
      than standard DECwindows clients.

	$ run decw$examples:ico

      You should see the bouncing icosahedron appear on the SUN system.
      If not, this isn't a DECterm problem but something else. Please
      report back the error here.

   3. Start up DECterm:

	$ create/terminal	! DECterm will exit when you log out

		- or - 

	$ create/terminal/detach  ! DECterm will survive your log out

      You can type help create/term to explain the other options.

      You should see DECterm created on the SUN system. It is possible
      (likely?) that the SUN server will not have all the fonts that
      DECterm wants. In that case, you should copy the fonts.alias file
      contained in note 2509 of this conference to the SUN system and
      restart the server. There is an MIT X11 utility (lsfonts?) that 
      can be used to list the fonts to verify that the DECterm fonts are
      available.

      If this doesn't work, please post the results here.
  

    I managed to get a DECterm to display on a SUN running X11R3, but
    I had to change the DECW$TERMINAL.DAT to use the MIT font set because
    I kept getting font lookup errors that killed the DECterm.  I got
    hold of the X11R4 fonts, and they work really well.  For transport,
    we are using WIN/TCPv5.1 and VMS V5.3, but I've heard that this
    works with UCX also.  With WIN/TCP we had to do "xhost +" to allow
    access to everyone on the SUN side.  Other than this, the procedure
    in the last note should work, but DON'T DEFINE DECW$DISPLAY on the
    VMS side, for some reason this causes problems with the XtOpenDisplay
    call in DECW$TERMINAL.  If you need information on this, we do have
    this working right now, feel free to contact me via e-mail.

    Can you please post the details of the configuration that you
    now have working? What is the Sun system configuration? What
    software versions is it running? 

    The SUN is running SUN/OS4.0.1 with X11R3 and xnews, it is a SUN
    3/60 machine connected to a VAXStation 3100 running VMS V5.3 and
    Wollongong's WIN/TCP version 5.1.  With the X11R3 fonts, since the
    Terminal fonts are missing for DECTerm, we had to change the default
    fonts for DECTerm from "Terminal" to "Courier" by putting the
    correct entry in the DECW$TERMINAL.DAT file.  If you want to do
    it right, get the X11R4 fonts and run them through bdftosnf and
    mkfontdir to add them to the X11R3 font set.  There doesn't seem
    to have been any change in font formats from X11R3 to X11R4.
    
    When you have the fonts set up, make sure you have the program for
    tcpip_transport, I think it's called TCPIP_TRANSPORT.EXE and its
    in SYS$SYSTEM or SYS$SHARE or something.  This is documented in
    this notes file and the DECTERM notes file someplace.  If you are
    running VMS version 5.1 or 5.2, you can get a patch for this
    transport program and I think it'll work alright although I've only
    tried VMS v5.3.
    
    The procedure is to:
    
    	1) On the SUN, start the X server and allow access to the client
    
    		% xinit -- Xsun
                % xhost +              ! done from the xterm window
    
        2) On the VAX:
    
    		$ SET DISPLAY/CREATE/NODE="sunhostname"/TRANSPORT=WINTCP
    
    		! for Wollongong the TRANSPORT is WINTCP, for UCX
    		! the TRANSPORT is TCPIP
    
    		$ CREATE/TERMINAL
    
    
    This is all it took.  Make sure you use CREATE in the SET DISPLAY,
    and DONT DEFINE DECW$TERMINAL.  The controller will use the WSAn:
    that is created by SET DISPLAY/CREATE to set up the display name.
    You should get DECTerm mailboxes on the VAX/VMS side called:
    
    	        $ DECW$TERMINAL...sunnodename::0.0
    
    or something like that.  At first the two colons made me think
    that DECWindows was using DECnet transport, but it uses TCP/IP
    nonetheless.  It's really pretty simple and it works as advertised,
    but it won't work if you miss a piece of the puzzle.  Let me know
    if you have any problem with it.