Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!haven!decuac!shlump.nac.dec.com!michaud From: michaud@decvax.dec.com (Jeff Michaud) Newsgroups: comp.unix.ultrix Subject: Re: LAT Terminal Server Manager for Ultrix Keywords: DECnet, RMS, TCP/IP, ncp, transparent file access Message-ID: <4236@shlump.nac.dec.com> Date: 22 Aug 89 03:25:06 GMT References: <7706@cbmvax.UUCP> <7683@cbmvax.UUCP> <1989Aug16.233014.9741@acd4.UUCP> <4169@shlump.nac.dec.com> Sender: news@shlump.nac.dec.com Organization: DEC Lines: 112 > > > ..., 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@decwrl.dec.com michaud@decvax.dec.com| |DECnet-ULTRIX #include | \--------------------------------------------------------------/