Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
DEC Windows TCPIP forwarding
195 views
Skip to first unread message
Andrew Armstrong
May 15, 2013, 12:54:13 AM5/15/13
to
I am having difficulties forwarding X11 on my Vaxstation 4000-90 running OPENVMS 7.3. I have the display correctly configured, and I have allowed the
VAX's host name using xhost on the remote machine. create/terminal results in
the following:
%DECW-E-CANT_OPEN_DISPL, Can't open display.
Multinet /X11debug reports:
%X11DEBUG-I-STARTING, MultiNet X11 transport diagnostics starting...
%X11DEBUG-S-PASSEDALL, passed all X11 tests
However, the SYS$MANAGER:DECW$SERVER_0_ERROR.LOG notes that
DECW$TRANSPORT_COMMON image base address: 00001200
DECW$TRANSPORT_DECNET image base address: 00887600
%DECW-I-ATTACHED, transport DECNET attached to its network
DECW$TRANSPORT_LOCAL image base address: 00892800
DECW$TRANSPORT_TCPIP image base address: 00894A00
%DECW-W-ATT_FAIL, failed to attach transport TCPIP
-SYSTEM-F-NOLOGNAM, no logical name match
Wireshark also reports no activity from the VAX using any X11 based protocol
with the exception of XDM, which establishes a session, but does nothing.
(Which makes sense, considering that multinet probably contains the
connection side, and gets everything else from DECWINDOWS)
Now, this machine previously had UCX installed on it, which I uninstalled
because I can never manage to get it to work correctly with regards to DNS
resolution. My best guess is that there is some esoteric configuration file
that still has the UCX values that is screwing up X11. Is there a way to get
a more verbose output, and actually find the logical that's causing it to
choke? Other then that, where would the most likely trouble spots be?
VAX's host name using xhost on the remote machine. create/terminal results in
the following:
%DECW-E-CANT_OPEN_DISPL, Can't open display.
Multinet /X11debug reports:
%X11DEBUG-I-STARTING, MultiNet X11 transport diagnostics starting...
%X11DEBUG-S-PASSEDALL, passed all X11 tests
However, the SYS$MANAGER:DECW$SERVER_0_ERROR.LOG notes that
DECW$TRANSPORT_COMMON image base address: 00001200
DECW$TRANSPORT_DECNET image base address: 00887600
%DECW-I-ATTACHED, transport DECNET attached to its network
DECW$TRANSPORT_LOCAL image base address: 00892800
DECW$TRANSPORT_TCPIP image base address: 00894A00
%DECW-W-ATT_FAIL, failed to attach transport TCPIP
-SYSTEM-F-NOLOGNAM, no logical name match
Wireshark also reports no activity from the VAX using any X11 based protocol
with the exception of XDM, which establishes a session, but does nothing.
(Which makes sense, considering that multinet probably contains the
connection side, and gets everything else from DECWINDOWS)
Now, this machine previously had UCX installed on it, which I uninstalled
because I can never manage to get it to work correctly with regards to DNS
resolution. My best guess is that there is some esoteric configuration file
that still has the UCX values that is screwing up X11. Is there a way to get
a more verbose output, and actually find the logical that's causing it to
choke? Other then that, where would the most likely trouble spots be?
Steven Schweda
May 15, 2013, 8:51:51 AM5/15/13
to Steven M. Schweda
> %DECW-W-ATT_FAIL, failed to attach transport TCPIP
> -SYSTEM-F-NOLOGNAM, no logical name match
Sounds like a problem. Have you looked at the MultiNet
> -SYSTEM-F-NOLOGNAM, no logical name match
docs to see if "TCPIP" is the right thing to add to
DECW$SERVER_TRANSPORTS, or if there are other necessary steps
to make it work as an X transport?
> Wireshark also reports no activity [...]
If you don't have a working IP X transport, then a lack of
IP X traffic would not amaze me.
> Now, this machine previously had UCX installed on it, which I
> uninstalled because I can never manage to get it to work
I've never had any such trouble, but with that problem
description and my weak psychic powers, I can't suggest much.
> [...] My best guess is that there is some esoteric
> configuration file that still has the UCX values that is
> screwing up X11.
Wouldn't be my guess. Some actual MultiNet expert/user
> screwing up X11.
(or a manual) might have more info than I.
Bob Koehler
May 15, 2013, 10:26:47 AM5/15/13
to
In article <17499d75-6813-4a5e...@googlegroups.com>, Andrew Armstrong <anda...@gmail.com> writes:
What commands did you use to setup the display on each system? What
does SHOW DISPLAY show?
What commands did you use to setup the display on each system? What
does SHOW DISPLAY show?
Andrew Armstrong
May 15, 2013, 12:09:48 PM5/15/13
to
On Wednesday, May 15, 2013 8:26:49 AM UTC-5, Bob Koehler wrote:
Show DISP shows:
Device: WSA10: [super]
Node: 192.168.2.6
Transport: TCPIP
Server: 0
Screen: 0
>Sounds like a problem. Have you looked at the MultiNet
>docs to see if "TCPIP" is the right thing to add to
>DECW$SERVER_TRANSPORTS, or if there are other necessary steps
>to make it work as an X transport?
The command for the transport is the same for both UCX and Multinet. I've had
this work in the past before I reinstalled the operating system on this machine
(The hard drive was wiped due to operator error) . This was the reason that I
was suspicious of UCX, I'd never /actually/ uninstalled UCX from the machine
before. I'd just let it sit dormant. The only other difference that I can think
of is that this machine isn't patched. (The installation was after the end of
patch availability, and I'm not sure how many of the patches I actually have on
this machine.) There was a past post on vmsnet.networks.tcp-ip.multinet about
a similar problem, involving patches, but it appeared that the patches were to
Multinet, (To quote Geoff Bryant from process)
>There is an issue with VAX and VMS 7.3. There is an eco that is close to
>being released. Please contact our support folks about this. I will update
>your case listed in this message with info for support.
Since process was releasing the eco, one would assume the problem to be with Multinet, and since the version in question in that post was v4.3a, it's unlikely to be the same problem.
(Actually, rereading that post reminded me of something. There are two
differences between my current set up and past set ups. Multinet 5.4 was newly
released, thus I've never actually had it work before, in the past I was using
5.3. This may be the actually problem)
> In article <17499d75-6813-4a5e...@googlegroups.com>, Andrew Armstrong writes:
>
>
>
> What commands did you use to setup the display on each system? What
>
> does SHOW DISPLAY show?
set display/crea /node=(laptop's IP address) /trans=tcpip
>
>
>
> What commands did you use to setup the display on each system? What
>
> does SHOW DISPLAY show?
Show DISP shows:
Device: WSA10: [super]
Node: 192.168.2.6
Transport: TCPIP
Server: 0
Screen: 0
>Sounds like a problem. Have you looked at the MultiNet
>docs to see if "TCPIP" is the right thing to add to
>DECW$SERVER_TRANSPORTS, or if there are other necessary steps
>to make it work as an X transport?
this work in the past before I reinstalled the operating system on this machine
(The hard drive was wiped due to operator error) . This was the reason that I
was suspicious of UCX, I'd never /actually/ uninstalled UCX from the machine
before. I'd just let it sit dormant. The only other difference that I can think
of is that this machine isn't patched. (The installation was after the end of
patch availability, and I'm not sure how many of the patches I actually have on
this machine.) There was a past post on vmsnet.networks.tcp-ip.multinet about
a similar problem, involving patches, but it appeared that the patches were to
Multinet, (To quote Geoff Bryant from process)
>There is an issue with VAX and VMS 7.3. There is an eco that is close to
>being released. Please contact our support folks about this. I will update
>your case listed in this message with info for support.
Since process was releasing the eco, one would assume the problem to be with Multinet, and since the version in question in that post was v4.3a, it's unlikely to be the same problem.
(Actually, rereading that post reminded me of something. There are two
differences between my current set up and past set ups. Multinet 5.4 was newly
released, thus I've never actually had it work before, in the past I was using
5.3. This may be the actually problem)
Bob Koehler
May 15, 2013, 2:32:55 PM5/15/13
to
In article <6c2df1b6-c056-4349...@googlegroups.com>, Andrew Armstrong <anda...@gmail.com> writes:
>
> set display/crea /node=(laptop's IP address) /trans=tcpip
>
> Show DISP shows:
>
> Device: WSA10: [super]
> Node: 192.168.2.6
> Transport: TCPIP
> Server: 0
> Screen: 0
Assuming the laptop is at 192.168.2.6, that look's good.
>
> set display/crea /node=(laptop's IP address) /trans=tcpip
>
> Show DISP shows:
>
> Device: WSA10: [super]
> Node: 192.168.2.6
> Transport: TCPIP
> Server: 0
> Screen: 0
I think I recall a problem in the past with Multinet's X11 TCPIP
transport image not being automagically installed into the correct
directory.
Andrew Armstrong
May 15, 2013, 1:34:25 PM5/15/13
to
I've found a multinet 5.3 kit on a simh vax. Is it worth a try to install 5.3,
and see if that would work?
Andrew Armstrong
May 15, 2013, 1:41:02 PM5/15/13
to
see if I can the problem you mentioned. Was this something new with multinet
5.4?
Andrew Armstrong
May 15, 2013, 1:52:56 PM5/15/13
to
On Tuesday, May 14, 2013 11:54:13 PM UTC-5, Andrew Armstrong wrote:
IP Address. Both show /network, and multinet /configure show show the IP
Address as 192.168.2.4. It is really 192.168.2.8. At first I thought this was
an artifact of show/network not being updated by DHCP, but the ip address
shown by MULTINET configure/menu is as the value in the form for the
interface is 0.0.0.0, with DHCP enabled. NFS, and telnet work, so I'm not sure
if this is a red herring.
Bob Koehler
May 17, 2013, 10:16:53 AM5/17/13
to
In article <78967eb8-294c-4979...@googlegroups.com>, Andrew Armstrong <anda...@gmail.com> writes:
>
> The laptop is 192.168.2.6. I guess I'll try and comb through comp.os.vms and
> see if I can the problem you mentioned. Was this something new with multinet
> 5.4?
I don't recall this being specific to any version, I just seem to
>
> The laptop is 192.168.2.6. I guess I'll try and comb through comp.os.vms and
> see if I can the problem you mentioned. Was this something new with multinet
> 5.4?
recall having to manually copy the file. Memory is vague, though, it
could have been the mail transport instead of X11.
Andrew Armstrong
May 20, 2013, 1:41:05 PM5/20/13
to
entries:
$ !
$ ! Install X11 transport
$ !
If F$Search("SYS$SHARE:DECW$TRANSPORT_MULTINET.EXE") .Nes. "" Then -
Install Add SYS$SHARE:DECW$TRANSPORT_MULTINET/Open/Share/Header/Protect
I think (I really don't know that much dcl) that the purpose of this is to
install SYS$SHARE:DECW$TRANSPORT_MULTINET.EXE (if it exists). My computer
does not have this file, and I couldn't find any file matching the pattern
*transport*.* (or *DECW*.*) in any of the files in the multinet kit. Do you
know where the file might be?
fbouch...@gmail.com
Jun 7, 2016, 3:18:58 PM6/7/16
to
@TCPIP$CONFIG
select server config
select XDM
select ENABLE and Start on this node.
exit
It then worked for me.
Francois Boucher
Hans Bachner
Jun 7, 2016, 8:07:23 PM6/7/16
to
On Wednesday, May 15, 2013 at 12:54:13 AM UTC-4, Andrew Armstrong wrote:
> I am having difficulties forwarding X11 on my Vaxstation 4000-90 running OPENVMS 7.3. I have the display correctly configured, and I have allowed the
> VAX's host name using xhost on the remote machine. create/terminal results in
> the following:
>
> [snip]
> I am having difficulties forwarding X11 on my Vaxstation 4000-90 running OPENVMS 7.3. I have the display correctly configured, and I have allowed the
> VAX's host name using xhost on the remote machine. create/terminal results in
> the following:
>
> DECW$TRANSPORT_COMMON image base address: 00001200
> DECW$TRANSPORT_DECNET image base address: 00887600
> %DECW-I-ATTACHED, transport DECNET attached to its network
> DECW$TRANSPORT_LOCAL image base address: 00892800
> DECW$TRANSPORT_TCPIP image base address: 00894A00
> %DECW-W-ATT_FAIL, failed to attach transport TCPIP
> -SYSTEM-F-NOLOGNAM, no logical name match
>
> [snip]
> DECW$TRANSPORT_DECNET image base address: 00887600
> %DECW-I-ATTACHED, transport DECNET attached to its network
> DECW$TRANSPORT_LOCAL image base address: 00892800
> DECW$TRANSPORT_TCPIP image base address: 00894A00
> %DECW-W-ATT_FAIL, failed to attach transport TCPIP
> -SYSTEM-F-NOLOGNAM, no logical name match
>
> Now, this machine previously had UCX installed on it, which I uninstalled
> because I can never manage to get it to work correctly with regards to DNS
> resolution. My best guess is that there is some esoteric configuration file
> that still has the UCX values that is screwing up X11. Is there a way to get
> a more verbose output, and actually find the logical that's causing it to
> choke? Other then that, where would the most likely trouble spots be?
Look into SYS$MANAGER:DECW$PRIVATE_SERVER_SETUP.COM and search for the
> because I can never manage to get it to work correctly with regards to DNS
> resolution. My best guess is that there is some esoteric configuration file
> that still has the UCX values that is screwing up X11. Is there a way to get
> a more verbose output, and actually find the logical that's causing it to
> choke? Other then that, where would the most likely trouble spots be?
decw$server_transports symbol definition. It probably includes "TCPIP".
There may be multiple definitions of this symbol - check which one is
used for your paricular VAX and remove the TCPIP transport from this
definition.
Then restart your DECwindows server and you should be all set.
Hope this helps,
Hans.
0 new messages