• Please review our updated Terms and Rules here

Looking for "VAXELN Window Server for Ultrix" manual

osf1

Member
Joined
Apr 8, 2021
Messages
16
Hi all,
I would like to use my vaxstation 3100 SPX as a X terminal for my microvax 3100 running Ultrix 4.5. I've found the VAXELN window server 1.2 (EWS120) on one Ultrix condist CD and installed it. The vaxstation boots and starts the X server, but doesn't start a decwin session. I've tried to trace the cause but only found, that dxsession issues a "X Toolkit Error: Can't Open display". As the kit only contains the OpenVMS installation manual, I wonder, if I'm missing some configuration steps, as there should also be an Ultrix install manual (VAXELN Window Server Installation Guide for ULTRIX Systems), but this is nowhere to be found.
So, my question is, does someone have this and could provide a scan or point me to a location, where I could get this? Or is someone familiar with the Ultrix configuration of EWS?
I also have OpenVMS running on my microvax and got EWS successfully running, so the vaxstation boots and starts the decwindows session.
Tnx.
Winfried
 
Unix guy here, so this may be unhelpful. "X Toolkit Error: Can't Open display" usually means one of two things, either X access is denied, or the host could not be found. Do you have your hostname, networking and resolver set up correctly? If dxsession is trying to access ':0' that would require that localhost be resolvable and reachable via TCP. I seem to remember that if it's trying '::0' that means localhost but via Decnet (I could be wrong on this). Otherwise I would expect that 'hostname:0' or 'hostname.my.domain:0' again be resolvable and reachable. I would expect that Xauth would be allowable automatically for either of the localhost variants, but with the hostname and hostname.fdqn, you may need to find some way of doing 'xhost hostname' (or 'xhost +' if you don't really care about opening the display up to the world).
 
Unix guy here, so this may be unhelpful. "X Toolkit Error: Can't Open display" usually means one of two things, either X access is denied, or the host could not be found. Do you have your hostname, networking and resolver set up correctly? If dxsession is trying to access ':0' that would require that localhost be resolvable and reachable via TCP. I seem to remember that if it's trying '::0' that means localhost but via Decnet (I could be wrong on this). Otherwise I would expect that 'hostname:0' or 'hostname.my.domain:0' again be resolvable and reachable. I would expect that Xauth would be allowable automatically for either of the localhost variants, but with the hostname and hostname.fdqn, you may need to find some way of doing 'xhost hostname' (or 'xhost +' if you don't really care about opening the display up to the world).
Thanks for your reply, but the hostname resolution is working fine and I've tried over both decnet and tcp/ip with the same result. My assumption was some authority settings, which are required on the X server side, which would have to be somehow configured in Ultrix, but couldn't find anything helpful.
 
This might be a dumb question, but would you in general use TCP/IP or DECNET for this? I assume TCP/IP but with DEC you never know what the default is.
 
Both Decnet and TCP/IP are configured. I've tried to configure the X terminal (node name vs1300) either with Decnet or TCP/IP or both and created two $LOGIN_HOST entries in /etc/ewsgeneric.dat, but there is no difference in the result. dxsession tries to connect either to the display "vs1300:0.0" (TCP/IP) or "vs1300::0.0" (Decnet), but for both cases, the result is the same: the session can't be started. As for the OpenVMS setup of EWS, some settings must be adjusted using autogen, so I don't know, if for Ultrix, also something in the kernel configuration must be added or changed, therefore I would like to get my hands on the Ultrix installation manual for this.
 
Finally, I've found the issue: xdm needs to run and/or started from rc.local. I wasn't aware of this, as I thought, ewsd would handle the creation of the session completely, as it already starts "login" with "EWSprompter" and "dxsession" (which failed as described above). But with a running xdm, the login window appears and I can login to decwindows. Now I have to configure Xstartup and Xsession accordingly. I've found this, while trying to get VXT-2.1 running alternatively, where an Ultrix installation document is available and describes this step. I assume, this is also in the EWS install document for Ultrix, which I still would like to find.
 
Furthermore, if the Xserver has a logging perhaps you can see if a connection attempt was ever made by dxsession, that should tell you if you have a resolver/reachable error or an X authentication error.
 
If it is TCP/IP,
pick out wireshark and listen to the traffic, including being able to disassemble the X11 packets.

X toolkit error : is that logged on the microvax 3100 server ?
I'm a bit unsure of who in this case starts the XDMCP session (but it should be the x server ie running on the spx) so you should see xdmcp packets from that one.
 
Thanks, but the issue wasn't directly network related but the not running xdm daemon, see my previous email, describing the problem and solution.
 
the EWS X terminal (VAXELN window server) doesn't use any local storage and everything is loaded from the host (the microvax). xdm uses the local Xsession/Xstartup.
 
Off topic question, but are the thread posts inserted in the user's local time? I see there are posts made after my last that have since been inserted into the conversation before mine. I can only surmise that it's a timezone thing and my BST (GMT +1 DST), is preceded by others' UTC-?
 
If it is TCP/IP,
pick out wireshark and listen to the traffic, including being able to disassemble the X11 packets.
Side track: I would assume that Wireshark also understands DECNET. Not sure if it can extract X11 packets sent over DECNET though. Given that it's open source and the code to interpret packets probably doesn't "cost" any performance to speak of, I assume that enthusiasts have over the years added support for X over DECNET :)
 
Back
Top