DCL and EDT for Unix?

Dave Sill de5 at ornl.gov
Sat Jun 22 03:12:40 AEST 1991


In article <1991Jun20.212124.22288 at convex.com>, jgardner at convex.com (John B. Gardner) writes:
>Summary: I stand by my post : -)

And I by mine.  I guess we'll just have to agree to disagree on this
topic since neither of us is convincing the other.

The Grand Master did a respectable job of answering most of these
points, but there're one or two comments I'd like to make.

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

I thought we were comparing UNIX vs. a VMS emulation.  The original
poster said they were switching their VMS shop to UNIX boxes and
wanted to make them lokk like VMS boxes.  My response was in this
context.

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

I see it differently.  In the given scenario, the decision to replace
the VMS boxes with UNIX boxes has already been made.  Since the search
for VMS compatability software was done after the fact, such software
must not have been a critical factor when the decision to switch to
UNIX was made, or they'd have been to locate the software before
making the switch.  Hence, management must have accepted the
implications of the move to UNIX, e.g., retooling the VMS users.  My
position is that to attempt to overlay VMS at this point is wrong
because it will delay the transition to UNIX and add unexpected costs.

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

Uh uh, it's the job of the people that decided to buy UNIX boxes in
the first place.  No doubt, though, they've planned for this and won't
swap the system out from under a project.

>Not to mention that some die-hard VMS hackers simply _refuse_ to learn UNIX,
>shall we just fire them?

In a heartbeat.  If management decides to go to UNIX, then
programmers/users have the choice of following along or not.  The
company's not obligated to run VMS forever, or to pay employees that
don't produce.

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

I guess, because if you convinced the board that VMS users wouldn't
notice a switch to UNICOS you really screwed up bad.  But really, this
is a different scenario than the original poster's.  I have nothing
against mixed shops providing emulations, *provided* they're aware of
the extra costs at decision making time.

-- 
Dave Sill (de5 at ornl.gov)	  Tug on anything in nature and you will find
Martin Marietta Energy Systems    it connected to everything else.
Workstation Support                                             --John Muir



More information about the Comp.unix.shell mailing list