Starting a terminal from dec-windows

[Niall76]

Hi,

I have just logged into an old system using Dec-windows for the first time in years, maybe ever. Dec Windows starts fine, but for some reasons i cannot open an terminal session in dec windows. Telneting or setting Host is fine to the box. Does anyone have any idea what the problem is? It running OpenVMS 7.3 and as far as i know, Dec-windows 4.

Thanks,

Niall

[Richard Whalen]

does sys$system:pcx$server.com exist and is it world readable?

[Hoff]

OpenVMS VAX or OpenVMS Alpha V7.3, and confirm the DECwindows version? (I'd guess that was 1.4 and not 4.)

$ SHOW SYSTEM /NOPROCESS

gets the OpenVMS system version (V7.3 here, apparently -- OpenVMS does not have a good central display of its core OpenVMS and installed product and hardware configuration, unfortunately), and the following gets the DECwindows version:

$ @sys$update:decw$versions
DECwindows ident is DW V1.6-060620
DECwindows server ident is DW V8.3-060629
DECwindows transport ident is DW V8.3-060629
DECwindows xlib ident is DW V1.6-060620
DECwindows OSF/Motif Toolkit ident is DW V1.6-060620
DECwindows apps ident is DW V1.6-060620
DECwindows programming ident is DW V1.6-060620
DECwindows LBX utilities ident is DW V8.3-060629
DECwindows LBX proxy server ident is DW V1.6-060620
$

The usual trigger for these cases is a bogus ssh command into the host, or configuration or operational problems with the X Windows client or the DECwindows server, or network errors. Or the X Windows client is not set up to allow in-bound X connections, if you're not using ssh.

But we need to know what you did and what errors you received. Specific commands, specific errors. And some details around your X Window client and X Window (DECwindows) server configuration is here; whether this is local, or whether you're using remote DECwindows displays to an X Window server running on a Mac or Windows or Linux or OpenVMS box.

Here are some write-ups on this area that'll hopefully give you some background and some ideas on how this stuff works:

http://64.223.189.234/node/134
http://64.223.189.234/node/1121

HP also has DECwindows User and configuration documentation posted at http://www.hp.com/go/openvms/doc - if you've not at least skimmed through the user documentation and the configuration documentation for that product, well, now is the time...

[Hoff]

Mr Whalen is assuming you're using a remote PC-based X Window display and the pcx$server is part of the eXcursion X Window server found on various PC boxes when PATHWORKS 32 client and the PATHWORKS Server pieces are installed. All of which may be valid here. I'm not assuming the display nor the display interface path quite yet; there are many ways to do this, including local displays, ssh displays, and straight X transports from OpenVMS and DECwindows over to your average X Window Server boxes.

And do look carefully at what is an X Window Client and an X Window Server here. The terminology can look a little odd; the client is the X application, and the X server is the box that's driving the display. And where those particular pieces are running can vary.

[Niall76]

Guy's, sorry i did not give enough information first time. It is openVMS 7.3 running on an Alpha 1200 server.

I have a HP920 monitor which I know works fine.

I rebooted the server and at the login screen i entered my username (system account) and password. DEC windows starts fine, I can open up "style manager", text editors, "explorers". When i click on the DECterm icon, nothing happens. Everything else appears fine.

I was thinking that it may have somthing to do with quotas?

Below is the information requested:
RACHEL::CONSOLE> @sys$update:decw$versions
DECwindows ident is DW T1.2-6010222
DECwindows server ident is DW V7.1-010317
DECwindows transport ident is DW V7.3-010820
DECwindows xlib ident is DW T1.2-6010222
DECwindows OSF/Motif Toolkit ident is DW T1.2-6010222
DECwindows apps ident is DW V1.2-6010222
DECwindows programming ident is DW T1.2-6010222
RACHEL::CONSOLE> dir sys$system:pcx$server.com
%DIRECT-W-NOFILES, no files found
RACHEL::CONSOLE>

[Volker Halle]

Niall,

there could be a problem in SYLOGIN.COM or LOGIN.COM

If you log in via TELNET, do you see any error messages after login and before reaching the DCL prompt ?

Volker.

[Hakan Zanderau ( Anders]

Just to be sure.....

Have you tried a different account ?

Hakan Zanderau
HA-solutions

[Hoff]

That DECwindows version looks a little stinky; that looks like a field test version. Was this box used for a field test at some point?

I'd expect to see a V1.2-x here. The V-prefix typically indicates a released version.

As for what is happening here, I'd see if there was anything interesting and relevant in the SYS$MANAGER:DECW$*.LOG files.

And yes, do definitely check LOGIN.COM and SYLOGIN.COM - and DECW$LOGIN.COM. Stick an $ EXIT at the top of each, and try again. No INQUIRE and no READ commands in those; no user prompts.

Also look at the CREATE /TERMINAL command, and see if there are any errors.

It's also possible that one of the DECterm configuration files is messed up.

See if ACCOUNTING data shows any process exits around the time of the failure, too. HELP ACCOUNTING /SINCE and such for details of that command. Pick something a couple of minutes ahead of when you tried the DECterm operation.

DECwindows and DECterm is sensitive to the system configuration and to the process quotas, too. Ensure the username has sufficient quotas per the documentation for this OpenVMS Alpha V7.3 box. DECwindows per-process quotas for recent versions are here:

http://64.223.189.234/node/49

As for the version, look for DWMOTIF* stuff and the product version in the following:

$ PRODUCT SHOW PRODUCT

The other installation path is via VMSINSTAL and that stuff gets logged in SYS$UPDATE:VMSINSTAL.HISTORY, but I'd not expect to see DECwindows installed that way.

I'd want to be on one of the upper-end V1.2-x versions, or later. And not on a T-prefix field test version.

This configuration is unrelated to PCX$SERVER. That's something rather different; that's a different X Window access path.

[Niall76]

SUCCESS!

I found out that someone installed OPENSSL on the box, but made a bit of a dogs dinner of it. I changed the startup com files to point to the correct areas of the install and rebooted. My terminals are back! yeah.
Sorry Hoff, I should have check what you were saying more closely first post.

Thanks everybody for your help.