| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 1004.1 | | VESTA::BAILEY | Eight or bust....... | Thu Jun 22 1989 12:36 | 8 |
| WAG.. does the VS2000 know about the node VSII???
Try
(on the VS2000) MC NCP SHO NODE vsii
|
| 1004.2 | yep | UNTAD8::BACHNER | Austrian Garfield - I hate Mondays | Fri Jun 23 1989 05:53 | 6 |
| Yes, both nodes know about each other.
Anything else to look for ?
Hans.
|
| 1004.3 | | STAR::THOMAS | Ben Thomas | Fri Jun 23 1989 11:32 | 5 |
| This sounds like something that I saw just recently. If the order of
DECnet and DECwindows startup is reversed, then most everything will
seem to work, but you may get failures like you are seeing. As I
recall, you can check to see if the X$X0 object exists.
|
| 1004.4 | decw$display logical | TOOK::L_OUELLETTE | | Fri Jun 23 1989 12:27 | 12 |
| Try the following:
define decw$display nodename::0 - where nodename is the node where
the output is to be displayed.
I find this works for me (using Notes) - I'm not sure why some applications
(seem to) require that this be done (DTM 3.0??).
I'd love an explanation if anyone has any ideas!
LarryO
|
| 1004.5 | better error messages from ICO | NEURON::NICHOLSON | A belly as big as an oil spill | Sun Jun 25 1989 18:03 | 9 |
| You might get a better error message if you ran DECW$EXAMPLES:ICO
(instead of NOTES) from your remote node. ICO is an XLIB program
and tends to give you an error message more descriptive than
X Toolkit Error: Can't Open display
%DWT-F-DWTABORT, xtoolkit fatal error
But it sounds like you're problem is with DECNET.
|
| 1004.6 | Network object unknown | UNTAD8::BACHNER | Austrian Garfield - I hate Mondays | Mon Jun 26 1989 04:47 | 20 |
| Thanks for the pointer to ICO. It really helped me to get one step further.
My info in .0 about not observing a login attempt on the displaying VS2000 was
not correct. I only enabled security alarms for Logins instead of Logfails.
After realizing this, I found that DECwindows attempted to use the DECnet TASK
object - which is disabled for DECnet default access (according to the security
guidelines).
After adding a proxy record, I got a different message:
network object unknown on remote node
Unfortunately ICO did not tell me which object it tried to access. Neither did
I find a reference to the X$XO object mentioned in a previous reply. Can anybody
advise me how to proceed ? Pointers to the relevant documentation are also
welcome.
Thanks for all the previous and coming help,
Hans.
|
| 1004.7 | | R2ME2::HARROW | POSIX what? | Mon Jun 26 1989 09:28 | 23 |
| The X$X0 is a DECnet object defined during DECwindows startup. To see
if it exists do the following:
RUN SYS$SYSTEM:NCP
SHOW KNOWN OBJECTS
Since the message you receive is "Network object is unknown" it is
likely that X$X0 will not be there. Something during startup probably
isn't happening correctly. As mentioned earlier, one why this could
happen is that DECwindows is started before DECnet and thus cannot
create that object.
Try doing an @SYS$MANAGER:DECW$STARTUP RESTART. Actually, you might
want to do this from a terminal instead of a window so that you can monitor
it's progress and the errors don't get erased when the server shuts down.
This will restart DECwindows (all windows will be deleted so make sure
nothing important is running). When this completes and you login, you
should be able to run your remote application. If it doesn't work, you
should have received an error message as it tried to create the X$X0
object. Good Luck.
-Jer
|
| 1004.8 | I bet you it's... | NEURON::NICHOLSON | A belly as big as an oil spill | Mon Jun 26 1989 22:47 | 10 |
| If you have a logical "DECNET" defined, then you can get the problem
you are seeing. In DECW$STARTSERVER.COM, the logical
DECW$SERVER_TRANSPORTS is defined to be the strings DECNET & LOCAL.
If you have a logical defined using either of those names then the
server will NOT load that transport (which would account for $X$0
not being there).
Do a $SHOW LOGICAL DECNET to see if that's the problem.
|
| 1004.9 | You've won your bet | UNTADT::BACHNER | Austrian Garfield - I hate Mondays | Tue Jun 27 1989 03:46 | 15 |
| Indeed, the problem was a system wide logical name DECNET pointing to our
DECnet default directory. I removed the definition and SET DISPLAY now just
works fine (except for the fact that defaults are not as described in the
documentation - but that's another story).
This reply is written on the VS2000 displaying windows from Notes running on
the MVII.
Thanks a lot for your help,
Hans.
PS: To the author of .8: when you ever come to Munich, let me know - you'll
have a beer for free in the Biergarten :-)
|
| 1004.10 | | STAR::ORGOVAN | Vince Orgovan | Tue Jun 27 1989 08:14 | 9 |
| Yes this is a problem with the V1 DECwindows startup. For both V5.1
and V5.2, the logical names "decnet" and "local" are translated to
construct the names of the server transport shareable images to be
loaded. If either is defined system-wide, you get symptoms like the
ones described above.
This portion of DECwindows startup has been reworked in V2 to remedy
the problem.
|