| With a little use of DIRECTORY/TITLE="TCP" or some other string you'll
find discussion of this _in_depth_.
I'll offer a summary as I present it (without a discussion of
futures)... Part of DECwindows is an implementation of the MIT X
Window System. The wise people at MIT decided to describe a set of
facilities for transport, not specify an implementation of them.
Therefore X "just calls" routines and has no need to know the specifics
of the transport. The method of transport is specified in the call to
XOpenDisplay, and syntax is defined there for DECnet, TCP/IP, and UNIX
sockets.
DECwindows version 1 represents a set of tradeoffs to achieve an
industry breaktrough in providing enterprise-wide integration. That's
not marketing fluff but reality. No one has anything quite like it.
There's no need to apologize.
For VMS, DECnet is supported. For ULTRIX, DECnet and TCP are
supported. Through the CONNECTION product these networks can be
conbined. For VMS, product managers are aware and they always looking
for feedback from the field that will help prioritize what VMS needs.
(As a side issue, third party implementations of DECNET do exist. And
the corporation is trying to align large networks with OSI eventually.
By that's a rathole for another conference.)
|
| Thanks for the answer. I think that the slides in the presentation
were a little bit misleading, they showed a network of VMS, Ultrix,
MS-DOS and other vendors machines. This on its own wasn't too bad
but the way it was drawn implied that the VMS machine could access
the "other vendors" machines. With the slide there was no mention
of gateways etc.
It only goes to show that it can be dangerous to present something,
without good knowledge, using other peoples material.
Thanks again
James
|