VMS 5.5-2, DECwindows and remote X displays

[hans.h...@gmail.com]

Hi,

I would like to run VMS 5.5-2 with DECwindows using a remote X display (Xorg) instead of the QVSS frame buffer supported by simh (for resolution and color). Ideally, I would want the remote X server to be treated like the builtin frame buffer, i.e. I want to log in using the graphical login and take it from there. I don't think that this is directly supported, but can it made to run? What I've tried is:

- Define the display to DECwindows using SET DISPLAY/CREATE/TRANSPORT=TCPIP/NODE=<ip-address-of-machine-running-xserver>
- MCR DECW$STARTLOGIN

This nicely starts the username/password requester on the display and it accepts my login. Then, however, the clock cursor is displayed and nothing else happens on the display. On the console, I see the message "Network partner disconnected logical link" repeated every few seconds. I also see that there is a process with the name _WSA3: running LOGINOUT.EXE running for a while but it then exits and a new process with the same name is started. If I STOP that process, no new instance is started, but I need to restart the X server before I can bring up the login window again.

I can start DECW$SESSION and DECW$WINMGR manually from a telnet session, but when I do that, things don't work quite well. Some colors are wrong, and new windows don't receive focus.

Also, does anyone know how to get the DEC fonts into Xorg? I've successfully exported them using getbdf and converted them to PCF, but for some reason, Xorg silently ignores most of the fonts.

Thanks,
Hans

[Stephen Hoffman]

On 2018-07-22 21:21:58 +0000, hans.h...@gmail.com said:

> I would like to run VMS 5.5-2 with DECwindows using a remote X display
> (Xorg) instead of the QVSS frame buffer supported by simh (for
> resolution and color). Ideally, I would want the remote X server to be
> treated like the builtin frame buffer, i.e. I want to log in using the
> graphical login and take it from there.

Ah, okay. So you're trying to display the session manager remotely.
That's fairly typical.

> I don't think that this is directly supported, but can it made to run?
> What I've tried is:
>
> - Define the display to DECwindows using SET
> DISPLAY/CREATE/TRANSPORT=TCPIP/NODE=<ip-address-of-machine-running-xserver>
>
> - MCR DECW$STARTLOGIN

In brief and this assuming DECwindows CDE, that can look something like
the following:
$ set display /create /node=host_name_or_address /transport=tcpip
$ spawn /nowait run cde$system_defaults:[bin]dthello.exe
$ @cde$system_defaults:[bin]xsession.com
$ loginout

This sequence launches the DECwindows CDE DTSESSION.EXE session manager
from within XSESSION.COM, aiming it at the specified remote X Window
Server display.

>
> This nicely starts the username/password requester on the display and
> it accepts my login. Then, however, the clock cursor is displayed and
> nothing else happens on the display. On the console, I see the message
> "Network partner disconnected logical link" repeated every few seconds.
> I also see that there is a process with the name _WSA3: running
> LOGINOUT.EXE running for a while but it then exits and a new process
> with the same name is started. If I STOP that process, no new instance
> is started, but I need to restart the X server before I can bring up
> the login window again.

Try searching Google and Google Groups archive for the comp.os.vms
newsgroup (this newsgroup) for related details, and try searching the
simh mailing list archive. Lots of information around.

What's the target X server that you're using? That's probably a bigger
factor for these cases, too. Have you shut off absolutely all
security on that X server? Everything? DECwindows on OpenVMS VAX is
very old, and quite allergic to modern security. X in particular tends
to block connections lacking security.

> I can start DECW$SESSION and DECW$WINMGR manually from a telnet
> session, but when I do that, things don't work quite well. Some colors
> are wrong, and new windows don't receive focus.

Seems your X server might be misconfigured, or the OpenVMS X bits are
just too old.

> Also, does anyone know how to get the DEC fonts into Xorg? I've
> successfully exported them using getbdf and converted them to PCF, but
> for some reason, Xorg silently ignores most of the fonts.

Use the font server? For configuration details, see the available
DECwindows font daemon documentation, and materials related to the
DECW$XTERMINAL_FONT and DECW$INSTALL_XTERMINAL logical names. The
font server is known more classically as classically xfs, and known as
DECW$FD on OpenVMS.

A couple of previous discussions, there are probably more around...
Some discussions on key mapping and font-related discussions also
included...

https://groups.google.com/d/msg/comp.os.vms/h9rO3pGtzJU/IlxM7F1SExYJ
https://groups.google.com/d/msg/comp.os.vms/F7PuyzVqdhs/3ir0XpQpD64J
https://groups.google.com/d/msg/comp.os.vms/qtKeilpkfCg/bhqf5gq2PzQJ
https://groups.google.com/d/msg/comp.os.vms/zzdPFlgRpQQ/r-epoxx-uDAJ
https://groups.google.com/d/msg/comp.os.vms/8Rs7vOV-2bM/47DM58npmzYJ

etc...


--
Pure Personal Opinion | HoffmanLabs LLC

[hans.h...@gmail.com]

Am Sonntag, 22. Juli 2018 17:54:42 UTC-4 schrieb Stephen Hoffman:
> On 2018-07-22 21:21:58 +0000, hans.h...@gmail.com said:
> > I would like to run VMS 5.5-2 with DECwindows using a remote X display

> Ah, okay. So you're trying to display the session manager remotely.
> That's fairly typical.

While this is a typical thing to want, my particular problem is that I want to do this using VMS 5.5-2, which does not have CDE or a display manager. The reason why I want this is VAX LISP, which links against the DECwindows shared libraries of VMS 5.5 - On VMS 7.3, it does not even start in graphical mode.

> What's the target X server that you're using? That's probably a bigger
> factor for these cases, too. Have you shut off absolutely all
> security on that X server? Everything? DECwindows on OpenVMS VAX is
> very old, and quite allergic to modern security. X in particular tends
> to block connections lacking security.

I'm using Xorg using -ac to disable access control. I am open to suggestions as to what X server may work better with VMS 5.5, too.

I understand that newer versions of DECwindows play nicer with X terminals, but I'm particularly interested in this old version.

Thanks for the font server hint, I'll try whether I Xorg likes the fonts better if they're server from a font server.

-Hans

[Stephen Hoffman]

On 2018-07-22 21:21:58 +0000, hans.h...@gmail.com said:

> I would like to run VMS 5.5-2

ps: Is there a particular reason for using what is a really old
release, even for OpenVMS VAX? Try V7.3, to start with? Chasing yet
older bugs and older limitations can be less than fun...

[Stephen Hoffman]

On 2018-07-22 22:04:04 +0000, hans.h...@gmail.com said:

> Am Sonntag, 22. Juli 2018 17:54:42 UTC-4 schrieb Stephen Hoffman:
>> On 2018-07-22 21:21:58 +0000, hans.h...@gmail.com said:
>>> I would like to run VMS 5.5-2 with DECwindows using a remote X display>
>>> Ah, okay. So you're trying to display the session manager remotely.
>> That's fairly typical.
>
> While this is a typical thing to want, my particular problem is that I
> want to do this using VMS 5.5-2, which does not have CDE or a display
> manager. The reason why I want this is VAX LISP, which links against
> the DECwindows shared libraries of VMS 5.5 - On VMS 7.3, it does not
> even start in graphical mode.

What is the error that this Lisp package is encountering with the newer
DECwindows? Maybe something to do with the removal of Adobe
Postscript support?

> I'm m using Xorg using -ac to disable access control. I am open to

> suggestions as to what X server may work better with VMS 5.5, too.

I seriously doubt that switch disables enough here.

Or try Xming. Again, with all security disabled.

Magic cookies, everything.

Check the X server log for details on the failures, too.

> I understand that newer versions of DECwindows play nicer with X
> terminals, but I'm particularly interested in this old version.

Or use the command line? That's how things were commonly done back
then, after all.

[hb]

On 07/23/2018 12:04 AM, hans.h...@gmail.com wrote:
> The reason why I want this is VAX LISP, which links against the DECwindows shared libraries of VMS 5.5 - On VMS 7.3, it does not even start in graphical mode.
>

VAX LISP is not linked against the DECwindows shareable images.

What's the error?

Something like "Error in DWT:TOOLKIT-INITIALIZE: %LIB-E-KEYNOTFOU, key
not found in tree"?

Which indicates that LISP is dynamically activating the DECW$DWTLIBSHR
shareable image and that this image does not contain the global symbol,
LISP is looking for.

[hans.h...@gmail.com]

Am Montag, 23. Juli 2018 13:38:33 UTC+2 schrieb hb:
> On 07/23/2018 12:04 AM, hans.h...@gmail.com wrote:
> > The reason why I want this is VAX LISP, which links against the DECwindows shared libraries of VMS 5.5 - On VMS 7.3, it does not even start in graphical mode.
> >
>
> VAX LISP is not linked against the DECwindows shareable images.
>
> What's the error?
>
> Something like "Error in DWT:TOOLKIT-INITIALIZE: %LIB-E-KEYNOTFOU, key
> not found in tree"?

Yes.

> Which indicates that LISP is dynamically activating the DECW$DWTLIBSHR
> shareable image and that this image does not contain the global symbol,
> LISP is looking for.

My statement may not have been entirely correct, but you seem to confirm that there is an incompatibility between VAX LISP and the DECwindows libraries that are shipped with VMS 7.3 (or 6.x already, I did not try that).

Can you propose a solution or workaround?

[hb]

On 07/23/2018 03:12 PM, hans.h...@gmail.com wrote:
> My statement may not have been entirely correct, but you seem to confirm that there is an incompatibility between VAX LISP and the DECwindows libraries that are shipped with VMS 7.3 (or 6.x already, I did not try that).

It looks like the DECW$DWTLIBSHR image is not upward compatible. I found
a note in the Compaq DECwindows Motif for OpenVMS release notes, April
2001. To me it looks like this shareable image has no (useful) global
symbol at all. Whether this is intentional to avoid dynamic image
activation, I don't know. Someone with a DECwindows/Motif background on
VMS may have more information. VAX LISP was already discontinued when
this incompatible change was made.

> Can you propose a solution or workaround?

Like using an older set of shareable images? No.

[NOSKCAJ::RENSIE]

Back in those days, both Unix and VMS too-readily assumed control of
the desktop; the stock Xstartup or Xsession script (I forget which)
would unilaterally a) reset the X server's font path and b) replace
the RESOURCE_MANAGER property of the root window.

So, in addition to the advice already given here, you could try
defeating WSINIT in sys$common:[sysmgr]decw$private_apps_setup.com
by redefining

$ decw$sessioninit == "run sys$system:decw$wsinit"

or saving both your font path and resources before calling the
login box and restoring them after.

Use: xset q | grep fp
to return your current fontpath; and

Use: xrdb -query
to return your current resources

But first, try to catch the error. In addition to tailing the
X server's log, *do* check the client log in your home directory
sys$login:decw$sm.log. Default is on, but if off, turn on the
log file for the session manager; again see private_apps_setup.com

$ decw$sessionlog == "true"

Not being able to find a font is enough to cause some clients to
abort so look for missing font errors in the log files and then
aliasing a font you do have to the missing ones using fonts.alias .

If VMS is serving fonts over a transport your X server understands
check connection-to and listing of fonts from the fonserver with
xlsfonts. Serving X fonts is more trouble than its worth but once
important for licensing restrictions. Better just have local
fonts on your X server. Xorg has DECW support.

Lastly, do compare (as others have suggested) different X servers.
It will help understand which end X server/client the problem is.