SimH/VAX + DEC Windows + XDM

[smithfarm]

Hello. I've got OpenVMS 7.3 running under a hobbyist license in SimH on
a Linux box. The IP address of SimH/VAX is 192.168.1.1. The PAKs for
OpenVMS, TCPIP, and DEC Windows have all been loaded.

On SimH/VAX, I've got TCPIP installed and running, with telnet, ftp, and
xdm servers activated.

I've got another machine, 192.168.0.95, from which I'm trying to connect
to the SimH/VAX. I have the HOSTS file in SimH/VAX set up to see that
machine as F95.

Telnet from F95 (192.168.0.95) to SimH/VAX (192.168.1.1) works fine.

Ping from F95 to SimH/VAX and vice versa works fine.

Xnest from F95 to SimH/VAX does not work. I'm using the following
command on F95:

Xnest -geometry 800x600 -ac -query 192.168.1.1 :10

When I do this, a window opens and I see an XDM login dialog. I can
enter my SimH/VAX user name and password. After that the window goes
black and a few seconds later, instead of a DEC terminal, I get the
login dialog again.

My XDM_XSESSION.COM file:

$ set proc/priv=sysnam
$ set_display_cmd :=
"set display/create/node="'p1'"/transport=tcpip/executive_mode"
$ write sys$output set_display_cmd
$ set_display_cmd
$ create/terminal/wait/window_attributes=(icon=livvax, title=livterm)

Here's what I'm getting in F95_10.LOG:

p1 = F95:10
p2 =
set display/create/node=F95:10/transport=tcpip/executive_mode
%DECW-E-CANT_OPEN_DISPL, Can't open display
SMITHFARM job terminated at 4-SEP-2010 etc. etc.

In SYS$SPECIFIC:[TCPIP$XDM]TCPIP$XDM_RUN.LOG I get "normal successful
completion".

In SYS$SPECIFIC:[TCPIP$XDM.WORK]F95_10.ERR I get:
xdm error (pid 680): fatal IO error 65535 (invalid i/o channel)

Any ideas on what I'm missing and where to go from here?

Nathan

[Wilm Boerhout]

smithfarm mentioned on 6-9-2010 20:40:

Take it one step a a time instead of trying to automate everything at once.

I assume an X.11 display server is up and running on node "F95" and
basic TCP/IP functionality is working as you stated (ping working both
ways).

Then on SIMH VAX do:

$ SET DISP /CRE /NODE=F95 /TRAN=TCPIP
$ CREA /TERM

Tell us what happens.

/Wilm

[JF Mezei]

smithfarm wrote:

> My XDM_XSESSION.COM file:

I am not sure about this mechanism.

Normally, XDM would run DECW$SESSION.EXE which give your the decwindows
deskop and the "task bar" from which you can start programs. These
programs do not need to create a display because the decwidnows session
one is available to them under the logical DECW$DISPLAY

I would try the follwiong:

telnet to the vax:

SET disp/create command to your other box.
MC DECW$CLOCK
This should pop a clock on your workstation.

This will test that the VAX is allowed to open a window on the
workstation. If this fails, use the XHOST command on your workstation to
authorize the vax to open windows.

Second step:

telnet to the vax
SET DISP/CREATE to your other box.
MC DECW$SESSION

This should pop the "task bar" on your workstation from which you can
start dec terms and other applications.

Finally, rename that XDM_SESSION.COM file to something else and try to
run XDM normally.

Note that the VMS XDM does not work with every machine. It is old and
does not support MIT cookies (at least the vax one). But if you get as
far as entering your username, it is a good sign because you are past
that stage.

> set display/create/node=F95:10/transport=tcpip/executive_mode
> %DECW-E-CANT_OPEN_DISPL, Can't open display
> SMITHFARM job terminated at 4-SEP-2010 etc. etc.

SET DISPLAY does not actually open the display. It simply creates a
template device and sets the logical DECW$DISPLAY to the WSAx: device.
You can have it point to a non existent node and it won't complain.

The "Can't open displ" message would come from another command which
tries to open the display pointed by DECW$DISPLAY you just created.

[smithfarm]

Many thanks, Wilm and JF! I can now open a DEC terminal or clock on my
Ubuntu desktop! (Sorry for the exclamation points, but I've been messing
with this for over a week, so this is a breakthrough.)

As I suspected, the problem was with Ubuntu, not with OpenVMS. The
Ubuntu X server was not listening for TCP connections. ((OFFTOPIC ASIDE:
By googling I found lots of messages telling me how to make it listen,
but apparently Canonical gets its kicks by changing the GDM
configuration files around for every new version of Ubuntu, rendering
the googled instructions obsolete. As of Ubuntu 9.10, the right
configuration file to edit is /etc/gdm/gdm.schemas - change
security/DisallowTCP from "true" to "false".))

Anyway, back to the original problem of making it work in Xnest. Now
when I start an XDM connection to the VAX in Xnest, it runs the task bar
in the Xnest window (:10) but everything else gets displayed on the
Ubuntu desktop (:0.0, presumably). Thean, when I exit from the task bar,
it kills my Ubuntu desktop, which is not the behavior I'm looking for.
I'd like to have all the DEC Windows stuff run in the Xnest window. It's
just a matter of finding the relevant configuration options to make DEC
Windows use a particular server number instead of :0.0.

[Wilm Boerhout]

smithfarm mentioned on 7-9-2010 0:44:

You're welcome. This last issue is just a matter of specifying the
correct numbers in your $ SET DISPLAY command on SIMH VAX. Look for the
/SERVER and /SCREEN qualifiers.

/Wilm

[Joseph Huber]

smithfarm wrote:

[...]

>
> Anyway, back to the original problem of making it work in Xnest. Now
> when I start an XDM connection to the VAX in Xnest, it runs the task bar
> in the Xnest window (:10) but everything else gets displayed on the
> Ubuntu desktop (:0.0, presumably). Thean, when I exit from the task bar,
> it kills my Ubuntu desktop, which is not the behavior I'm looking for.
> I'd like to have all the DEC Windows stuff run in the Xnest window. It's
> just a matter of finding the relevant configuration options to make DEC
> Windows use a particular server number instead of :0.0.

XDM creates a display on VMS to the peer.
If You want everything displayed on the Xnest display, then DON't CREATE a
different display in xdm_xsession.com.
If the DECwindows session-manager is running to the Xnest display, then it
will not affect the Ubuntu display, unless Xnest does something strange. (I
have no experience with Xnest, but other X11 servers I never saw affecting
displays they are not owning).

--
Joseph Huber, http://www.huber-joseph.de

[smithfarm]

> XDM creates a display on VMS to the peer.
> If You want everything displayed on the Xnest display, then DON't CREATE a
> different display in xdm_xsession.com.
> If the DECwindows session-manager is running to the Xnest display, then it
> will not affect the Ubuntu display, unless Xnest does something strange. (I
> have no experience with Xnest, but other X11 servers I never saw affecting
> displays they are not owning).

What you say makes sense and you describe just the behavior I was
expecting. But the behavior I am seeing is different. It doesn't have
anything to do with the XDM_XSESSION.COM quoted above, because I already
got rid of that. What I am seeing is this: after logging in, the DEC
task bar opens in the Xnest window (display F95:10) but the background
color does not change (remains black). Immediately thereafter, the
background color on display F95:0.0 (which happens to be my Ubuntu
desktop) changes to DEC blue. Other windows that open, do so on display
:0.0 and not :10 as desired. When I exit from the task bar on :10, it
abruptly closes all these windows :0.0 and _shuts down the X server_.

No time to look into this now, but I will follow up here when I get to
the bottom of it. Time permitting, I'd like to write a HOW-TO for the
less experienced who want to delve into OpenVMS on commodity hardware.
Will post here if and when I actually do it.

[Wilm Boerhout]

smithfarm mentioned on 9-9-2010 21:59:

I'm using the following setups, depending on my mood and needs:

X Clients on CHARON-VAX, Personal Alpha, SIMH VAX on Windows,
X display servers: eXcursion, Xming, Reflection X, sometimes
simultaneously, each on it's own server address (:1,:2,:3 etc.), and the
Windows desktop as the actual physical display. The sessions and Windows
from the various VMS systems all wind up where I expect them, that is,
where the server part of the DECW$DISPLAY structure tells them to.

You *must* have an inadvertent X client process somewhere pointing to
display server :0 (in addition to :10). Please check the process list in
VMS carefully, and use $ ANALYZE /SYSTEM to check on the channels that
each process has open.

/Wilm

[JF Mezei]

One thing to consider:

VMS will try to take control of your display and install a "root" window
and manage the windows.

Modern desktops may not have a root window, so it becomes available for
VMS to take it over.

You could try to login with the "new desktop" (CDE). I am not sure if it
is an option under XDM though. New Desktop is closer to modern desktops.

Another thing to try:

telnet to the vax
SET DISPLAY/CREATE/EXEC to the proper destination.
MC DECW$LOGIN

This will give you the standard decwidnowd login, and that one does give
you an option to choose which desktop you want (decwidnows or CDE/New
desktop). It is also possible that this method, even with the old
desktop, could honour both the node and screen/display destination and
remain bounded inside your window.

[Richard B. Gilbert]

JF Mezei wrote:
> One thing to consider:
>
> VMS will try to take control of your display and install a "root" window
> and manage the windows.
>
> Modern desktops may not have a root window, so it becomes available for
> VMS to take it over.
>
> You could try to login with the "new desktop" (CDE). I am not sure if it
> is an option under XDM though. New Desktop is closer to modern desktops.
>
> Another thing to try:
>
> telnet to the vax
> SET DISPLAY/CREATE/EXEC to the proper destination.
> MC DECW$LOGIN
>
> This will give you the standard decwidnowd login, and that one does give
> you an option to choose which desktop you want (decwidnows or CDE/New

Has anybody noticed that JF is suffering from dylsexia?

<snip>