LAT Terminal Server Manager for Ultrix

[Jeff Michaud]

> > > ..., which, like DECnet, is sort of grafted onto the Unix networking
> > > while remaining it's own rather perverse view of the world...
> 
> > DECnet is not "grafted" onto Unix networking.  We use the same device drivers
> > as IP.  We are no more "grafted" on than IP, just that we aren't bundled with
> > the base system
> 
> By grafted, I mean that they did share the same "roots", the "network" device
> drivers.  I don't have any real problem with this.

	Do you have any "fake" problems with this :-))

> On the other hand, much
> of DECnet seems to me like an pear branch on an apple tree, some "generic DEC"
> code that happens to run under Unix.  

	Believe me, it isn't "generic DEC code".  In fact these days its more of
	the opposite.  Our ULTRIX implementation is getting transplanted into
	various other products (which I don't think I'm allowed to mention).

> The ncp(8) program and the Decnet
> "configuration" databasese aren't exactly in the unix idiom ...

	A given that managing DECnet with "ncp" vs. "editing files here and there and
	putting several incantations into rc.local" isn't very Unix like, but most
	people count that as a plus for DECnet that we have real network management.
	Remember also that "ncp" on one system can be used to manage almost any system
	on your network.  To do that "ncp" has to have consistent commands accross
	implementations.  Network management in IP space is only now starting to take
	some form.

> ... and can be quite
> excruciating, especially when ncp starts returning cryptic error messages ...

	At least it's returning error messages to let you know something is wrong.
	With IP you have to know what you are doing to even beable to figure out
	there is a problem :-), then guess which file you have to edit :-))).

> ... or when you've let it interactivly guide you thru entering a command and then
> you get a "syntax error" type message.

	Yup, I've had the same problem.  Looks like a bug to me, but now you
	are nit-picking away from why you believe DECnet is "grafted" onto
	Unix.

> It would be nice if it knew about
> the same "device names" as everybody else, too.

	"Everybody else" => "TCP/IP" :-)).  Yes it would be nice, as I too
	have been bit by specifing the wrong one at installation time.
	As a weak defense, if you just hit return (or type "?" return) at
	the "Which device do you want to run DECnet over" question, it will
	tell you the mappings between the DECnet name for devices and the IP
	name for them.

> By the way, now that we have all this nice "generic file system" stuff,
> why can't ultrix use the DECnet protocols for remote file access?

	I believe most people who have DECnet connectivity between ULTRIX systems
	also have IP connectivity, so can just use NFS.  For those who have
	only DECnet connectivity between ULTRIX system, I believe we have
	already product announced a product to help in that situation.

> In the
> long run, NFS servers running under VMS would seem more efficient, but
> for "convenience" purposes, the DECnet mode would be nice.

	DEC already sells NFS for VMS (I think the name is "Ultrix Connection
	Product" but I'm not sure).

> If I can access
> Ultrix files directly from VMS via DECnet, I out to be able to go the
> other way, without having to resort to command line style copy programs...

	Sounds like RMS-32 to me, which is a little more complex than the
	gfs (generic file system).  Also gfs is concerned with filesystems,
	but transparent DECnet access doesn't fall into this catagory
	since you want to be able to access any file on any system without
	having to mount the remote filesystem first.

	I've looked into it, as other have before me.  There are several
	tough problems to overcome.  One of the biggies is which syntax
	to use?  The ULTRIX filesystem allows filenames to contain any
	characters.  That means using :: syntax would make a remote file
	specification confict with an otherwise valid local file specification.
	Then we also have to allow access control to be specified in the
	remote file spec; but since the commands or utilties, or anything that
	read's process's command line from /dev/kmem know that a remote file
	spec contains accounts/password, it will displaying them in clear text.
	And then there is the problem with knowing whether the application that
	is operating on this file (that the application doesn't know is being
	accessed via DECnet transparent file access) wants read this file
	in ascii or binary mode (not to mention if it wants to lseek on an
	ascii file!).

	You keep saying DECnet looks like its "grated" on, but look at
	what you want! :-)  IP doesn't even provide transparent file access
	(which BTW would have to overcome all the same problems mentioned
	in the last paragraph) as you still have to resort to "command
	line style copy programs...".

	If a user written application today wants to give the illusion of
	transparent DECnet file access it would be rather trivial to create
	some jacket routines on top of fopen/fclose that recognize the syntax
	you choose to key it off that it should open a remote file, and then
	just use popen/pclose to kick off "dcp".  You could even put jacket
	routines over the routines described in directory(3) and stat(2).
-- 
/--------------------------------------------------------------\
|Jeff Michaud    michaud at decwrl.dec.com  michaud at decvax.dec.com|
|DECnet-ULTRIX   #include <standard/disclaimer.h>              |
\--------------------------------------------------------------/