DCL and EDT for Unix?

[John B. Gardner]

The following is not meant to be a flame, it's posted in the spirit of
maintaining accuracy.  :-)


In article <1991Jun20.182101.3145 at cs.utk.edu> Dave Sill <de5 at ornl.gov> writes:
>In article <1991Jun19.205450.26120 at convex.com>, jgardner at convex.com (John B. Gardner) writes:
>
>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.  :-) 

I am not trying to sell anything.  My post "objectively" listed observable
characteristics of VMS emulation packages.  And no, I'm not in the market
for any weapons, thanks anyway.  :-)


>
>>"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. 

Interesting logic.  Usually the existence of counterexamples _do_ invalidate
a premise.  I'm not going to take the energy to fully analyze _every_ DCL
emulation product, the ones I've used exhibit the characteristics I've 
listed, that's sufficient for me.


>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.

First, we're not comparing the efficiency of UNIX vs. VMS, we're comparing
VMS against a VMS emulation.  Second, even if we _do_ place the emulation 
against a "UNIX" shell (e.g. tcsh), your comments fail.  Tcsh still has file 
globing to do, command and filename completion, alias and environment variable
translation, etc, etc.  No _interpreted_ language is going to be blindingly 
fast, but a case by case comparison of the emulation vs. a UNIX shell doing 
approximately the same mix of operations comes out essentially a wash.  

The emulation doesn't "convert" the DCL to UNIX and then run it through 
another shell.  It operates directly over the OS, just like DCL does.  There 
is no conversion from qualifiers to options, the commands interpret the 
qualifiers directly, just as in DCL.  For example, if you enter "DIR" the 
emulation does NOT run "ls", it runs DIRECTORY.EXE, which is approximately 
as fast but totally different from the "ls" program.

The emulation can be just as fast as any other full-featured shell.


>>"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?

I don't have to prove _all_ do, I'm just showing at least _some_ do.  
As for compatiblity, yes it's obviously not DCL, but the additions are 
orthogonal to the DCL syntax, causing no compatibility problems.  Just like 
you can extend DCL using "SET COMMAND" to add you own commands to the base 
interpreter.


>>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.

You're missing the point.  The idea is not to force the user to the 
politically correct language.  What you should be doing is providing 
the mechanisms which allow the user to be most productive.  Either as
a transitional tool, one which simply allows the VMS/DCL user to be 
immediately productive on a UNIX platform, or as a very fast batch engine
to run VMS applications remotely, the emulations have their place.

If you're doing systems level, device driver, or i/o application development
you most certainly wouldn't do it through an emulator.  But if you're running
applications which have already been ported, viewing data on a UNIX system, 
or doing remote batch submission, why waste the time to learn a totally alien 
environment?

I know of some sites where the users sit at there VMS workstation, submit
jobs to a remote queue, get their data back, and don't even realize that it 
was a UNIX box running an emulation that did the work!


>>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*.

Which UNIX standard are you referring to? BSD 4.2?, System V?, sh?, ksh?,
tcsh?, csh?  Or which binary standard? ConvexOS?  Unicos?  Ultrix? SunOS?
Give me a break!  Just because it says "Unix"  does not mean you can just
hop on the machine and get work done, unless the machine happens to support
a flavor of UNIX you happen to understand.


>When in UNIX, do as the UNIXans do.  There's nothing innapropriate in
>expecting the users of a system to learn it.

Tell this to the stockholders when you have to explain a 6 month project
slip due to the re-education of all your users to an unfamiler environment.
Not to mention that some die-hard VMS hackers simply _refuse_ to learn UNIX,
shall we just fire them?


>If you need both, buy and run both.

Right, I just paid $32 million for a YMP-16, now I have to go back to the
board of directors and ask for another $3 million for a VAX 9000.  I guess
I better subscribe to misc.jobs.offered.


>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?

You are doing the readers of this group a disservice with this diatribe.
It is simply wrong.  If you've never used a good emulation package then
you probably shouldn't comment on their usefulness.  I've _experienced_
examples of complex VMS/DCL applications operated by VMS-only hackers 
running marrily away on UNIX boxes.  It's real, it works, believe it.


As usual, many tradmarks have been referrenced, these are my personal
comments only and do not reflect the view of any company.

--
   /\ /_  _    jgardner at convex.com
   \//_//_/
   /     /     "Poor is the man whose pleasures depend
  /    \/       on the permission of another" -Madonna