mjb@acd4.UUCP ( Mike Bryan ) (08/17/89)
Does anyone know of a software package which would allow an Ultrix host to maintain and control the setup of DECservers? We would like to keep the database of all port/server settings from many DECserver-200s on our VAX, in order to make management easier, and allow easy recovery from failed or accidentally-initialized DECservers. The 'ccr(8)' command can't even be used as a rough interface, as it seems to expect interactive use only. We are running both Ultrix 2.3 and 3.0, either would be suitable for such a package. Of course, free software would be preferred, but we would be interested in a commercial product if it is reasonably priced. (DEC does provide a Terminal Server Manager product for VMS, but not Ultrix. *Sigh*) Any responses via e-mail or followup postings would be greatly appreciated. Thanks in advance!! -- Mike Bryan, Applied Computing Devices, 100 N Campus Dr, Terre Haute IN 47802 Phone: 812/232-6051 FAX: 812/231-5280 Home: 812/232-0815 UUCP: uunet!acd4!mjb ARPA: acd4!mjb@uunet.uu.net "Did you make mankind after we made you?" --- XTC, "Dear God"
grr@cbmvax.UUCP (George Robbins) (08/17/89)
In article <1989Aug16.233014.9741@acd4.UUCP> mjb@acd4.UUCP ( Mike Bryan ) writes: > > Does anyone know of a software package which would allow an Ultrix > host to maintain and control the setup of DECservers? We would like > to keep the database of all port/server settings from many > DECserver-200s on our VAX, in order to make management easier, and > allow easy recovery from failed or accidentally-initialized > DECservers. The 'ccr(8)' command can't even be used as a rough > interface, as it seems to expect interactive use only. As far as I know there is nothing available to do this... > ... (DEC does provide a Terminal Server Manager product for VMS, > but not Ultrix. *Sigh*) This seems to be one of those areas, where for all the polite noises DEC makes about equal time for VMS and Ultrix, they have decided not to support certain functionality, excpept on a VMS platform. Not only is there no support for a TSM function, DEC doesn't seem to want to admit that the DECSA or DECserver 5XX series exist in the Ultrix world. I think you can actually do a downline load for a DECSA if you've prepared the image on a VMS system, but nothing in the manuals admits this and the silly dsvconfig script has the DS100 vs DS200 choice hardwired in Of course, the how to do whatever ccr(8) does is something that DEC has chosen not to document. This may not be so horrible, I've been looking at what lpd does to dynamically attach LAT connections, and it's gross! It's not a simple "lat_atttach" system call, rather there's a bunch of procedureal gruk that reflects that fact that LAT is neither TCP nor DECnet, rather it's more of a do-it-yourself talk direct to the ethernet I/F hack, which, like DECnet, is sort of grafted onto the Unix networking while remaining it's own rather perverse view of the world... -- George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@uunet.uu.net Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
davew@gvgpsa.GVG.TEK.COM (David C. White) (08/18/89)
In article <7683@cbmvax.UUCP> grr@cbmvax.UUCP (George Robbins) writes: >In article <1989Aug16.233014.9741@acd4.UUCP> mjb@acd4.UUCP ( Mike Bryan ) writes: >> >> Does anyone know of a software package which would allow an Ultrix >> host to maintain and control the setup of DECservers? We would like [deleted stuff about ccr] >As far as I know there is nothing available to do this... > >> ... (DEC does provide a Terminal Server Manager product for VMS, >> but not Ultrix. *Sigh*) I'm rather fortunate (dubious choice of words) that we have VMS systems in the bean-counting side of the house and they gave me privileges to use TSM, LTM, and RBMS so I can control terminal servers, lan traffic monitors and DEC LANbridges used on our predominately TCP/IP network on the engineering side! If I didn't have access to a VMS system, these devices would make good boat anchors since there is no way to get to a LTM or DEC bridge to do anything via Ultrix. >This seems to be one of those areas, where for all the polite noises DEC >makes about equal time for VMS and Ultrix, they have decided not to support >certain functionality, excpept on a VMS platform. Amen. They tossed us DECwrite for the VAXstation platforms, but kept the spreadsheet and graphics stuff that goes with it under the VMS umbrella. There is a rather humerous twist to all of this. I'm looking at changing our Vitalink TransLAN 350's to TransPATH 350's so I can get the TCP/IP routing capabilities, and in the course of doing so, found out about a package for mananging and monitoring Vitalinks *AND* DEC LANbridges called 802 WANmanager. Guess what it runs on? VAXstation platforms under Ultrix only! They even had a statement in their literature that a Unix-based platform was the best choice for a network management tool. I wonder if DEC and Vitalink are still on speaking terms. :-) -- Dave White Grass Valley Group, Inc. VOICE: +1 916.478.3052 P.O. Box 1114 Grass Valley, CA 95945 FAX: +1 916.478.3887 Internet: davew@gvgpsa.gvg.tek.com UUCP: ...!tektronix!gvgpsa!davew
michaud@decvax.dec.com (Jeff Michaud) (08/19/89)
In article <7683@cbmvax.UUCP>, grr@cbmvax.UUCP (George Robbins) writes: > It's not a simple "lat_atttach" system call, rather there's a bunch of > procedureal gruk that reflects that fact that LAT is neither TCP nor > DECnet, rather it's more of a do-it-yourself talk direct to the ethernet > I/F hack, 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 (though for the RISC/ULTRIX V3.0 the DECnet kernel components were bundled w/the the base system and even built into the kernel by default, so when you installed DECnet all it did was drop programs down, ask a few questions, then just turn it on). Also remember that "Unix networking" does not always imply IP (just as IP doesn't imply Unix :-). -- /--------------------------------------------------------------\ |Jeff Michaud michaud@decwrl.dec.com michaud@decvax.dec.com| |DECnet-ULTRIX #include <standard/disclaimer.h> | \--------------------------------------------------------------/
grr@cbmvax.UUCP (George Robbins) (08/19/89)
In article <4169@shlump.nac.dec.com> michaud@decvax.dec.com (Jeff Michaud) writes: > In article <7683@cbmvax.UUCP>, grr@cbmvax.UUCP (George Robbins) writes: > > ..., 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 Maybe we can agree to disagree or disagree to agree or simply become confused... By grafted, I mean that they did share the same "roots", the "network" device drivers. I don't have any real problem 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. The ncp(8) program and the Decnet "configuration" databasese aren't exactly in the unix idiom and can be quite excruciating, especially when ncp starts returning cryptic error messages or when you've let it interactivly guide you thru entering a command and then you get a "syntax error" type message. It would be nice if it knew about the same "device names" as everybody else, too. 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? In the long run, NFS servers running under VMS would seem more efficient, but for "convenience" purposes, the DECnet mode would be nice. 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... -- George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@uunet.uu.net Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
thomas@mipsbx.nac.dec.com (Matt Thomas) (08/20/89)
> Of course, the how to do whatever ccr(8) does is something that DEC has > chosen not to document. This may not be so horrible, I've been looking > at what lpd does to dynamically attach LAT connections, and it's gross! It is gross. No argument from me (no, I didn't write the code) on that. But that's one of the reasons lcp -h /dev/ttyxx:server:port was included in V3.0. So that the mechanics are taken care of in the kernel. Hopefully a better way will come along to do the dynamic attaching that lpd needs. It might even be done via an ioctl similar to LIOCTTYI. But then again, maybe not. > It's not a simple "lat_atttach" system call, rather there's a bunch of > procedureal gruk that reflects that fact that LAT is neither TCP nor > DECnet, rather it's more of a do-it-yourself talk direct to the ethernet > I/F hack, which, like DECnet, is sort of grafted onto the Unix networking > while remaining it's own rather perverse view of the world... Except for the HIC support (which I admit is not very pretty), LAT is very well integrated into the kernel. The LAT ttys are real ttys (not ptys which rlogin/telnet/dlogin use). LAT talks to the network interfaces just like IP or DECnet and talks to the tty code just like a DZ or DHU driver. Granted the code has its bugs and warts but it is getting better. -- Matt Thomas Internet: thomas@decwrl.dec.com DECnet-Ultrix Development UUCP: ...!decwrl!thomas Digital Equipment Corporation Disclaimer: This message reflects my own Littleton, MA warped views, etc.
michaud@decvax.dec.com (Jeff Michaud) (08/22/89)
> > > ..., 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 <standard/disclaimer.h> | \--------------------------------------------------------------/