Xref: utzoo comp.sys.dec:6084 comp.os.vms:40141 comp.editors:3403 comp.unix.shell:2458 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!emory!utkcs2!ornl.gov!de5 From: de5@ornl.gov (Dave Sill) Newsgroups: comp.sys.dec,comp.os.vms,comp.editors,comp.unix.shell Subject: Re: DCL and EDT for Unix? Keywords: DCL EDT Convex Message-ID: <1991Jun20.182101.3145@cs.utk.edu> Date: 20 Jun 91 18:21:01 GMT References: <91169.171310SCHDAVZ@YaleVM.YCC.Yale.Edu> <1991Jun19.122116.8961@cs.utk.edu> <1991Jun19.205450.26120@convex.com> Sender: usenet@cs.utk.edu (USENET News Poster) Reply-To: Dave Sill Distribution: usa Organization: Oak Ridge National Laboratory Lines: 71 In article <1991Jun19.205450.26120@convex.com>, jgardner@convex.com (John B. Gardner) writes: > >Ahhh, I totally disagree. Now granted I'm referring to COVUEshell, which >is available only on Convex machines, so won't help Mr. Schweisguth, but >I beleive VCL (BBC) et al have similer implementations. Well, I don't have a Martin Marietta product to push (wanna buy a Titan/Patriot/a-bomb?), so I guess I'll have to remain general and objective. :-) >"There will be lots of picky little incompatibilities" No, there isn't. >There _is_ greater flexibility... The existance of specific counterexamples doesn't invalid the general point. >"forcing everything through a VMS model is inefficient", No, it isn't. >The "emulation" is a C-compiled implementation of DCL, just like DCL is >a MACRO implementation of DCL. In the case of COVUEshell, the emulation >runs as a normal "UNIX shell" and is no less efficient than tcsh, csh, >or any other "normal" shell. It runs just as fast as on a native VMS >machine, faster in fact, if you take into account the available CPU power. Given two UNIX shells, one that is native UNIX and one that provides VMS compatability, I argue that the former is more efficient because it doesn't have to jump through the hoops of making UNIX look like VMS. It doesn't have to handle funky filename and directory specifications, version numbers, command aliases, VMS /qualifier to UNIX -option conversion, etc. >"and you won't be able to take advantage of the features of UNIX that make >it worthwhile", Not true. All available UNIX features are accessible >from within the emulation. Fine. Does *every* virtual VMS for UNIX do that? Do you do it without violating your VMS compatability? >And in "learn" mode every DCL command generates the corresponding UNIX >command that would do the same thing, a very effiecient means of learning >to use UNIX. That's a potentially useful feature during *transition* to to UNIX from VMS. That's not a reason to provide DCL forever. It also implies that a DCL -> shell convertor could be provided for porting shell scripts, which would also make it easier to make a clean break from VMS. >Keep in mind that VMS/DCL is a _very_ widespread and effective system. So what? So is UNIX/shell, which has the advantage in this case of being the system provided, and the general advantage of being vendor independent and *standard*. >Although _I_ happen to prefer UNIX as an everyday tool, it would be >inappropriate for me to demand the entire world follow suit. When in UNIX, do as the UNIXans do. There's nothing innapropriate in expecting the users of a system to learn it. >Each has its place, and using one of the emulation packages can allow >both to work in harmony. If you need both, buy and run both. UNIX and VMS (or DOS, or whatever) are like oil and water, and will never "work in harmony" on the same box. Hell, UNIX doesn't even work in harmony with *itself*, how you expect it to coexist with another OS? -- Dave Sill (de5@ornl.gov) Tug on anything in nature and you will find Martin Marietta Energy Systems it connected to everything else. Workstation Support --John Muir