Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!oliveb!pyramid!ctnews!mitisft!gm
From: gm@mitisft.Convergent.COM (G.M. Harding)
Newsgroups: comp.software-eng
Subject: Re: VMS vs. UNIX s/w development tools - query
Keywords: VMS UNIX tools
Message-ID: <600@mitisft.Convergent.COM>
Date: 30 Mar 89 21:54:40 GMT
Organization: Convergent Technologies, San Jose, CA
Lines: 128


An Open Letter to Ray Lillard:

     I've had a fair amount of development experience in both
the Unix and VMS environments. Like you, I prefer Unix. However,
VMS has some nice things about it, particularly its debugger
system. Many of the tools you mention are written in reasonably
portable C and can be (actually, have been) ported to VMS. I have
personally ported yacc, but since that's owned by AT&T you may
find it difficult to do likewise. Take a look at "bison" (from the
Free Software Foundation, I believe) which is supposed to be fully
yacc-compatible. For scanners, check out "flex," which was posted
in comp.sources.unix a while back (or write Rich Salz at uunet for
a copy).

     Yes, RE's are mostly missing from the VMS user interface, and
almost entirely missing from the VMS utilities, and that's a shame.
You just don't realize what RE's can do for you until you use them.
(On the other hand, VMS's "grep" equivalent has a contextual option
which displays not only the matched lines, but N lines before and
after--very nice, and something I've seen only on a couple of Unix
systems.) The VMS counterparts of "sccs" and "make" are serviceable
(though the last time I used CMS, years ago, it ran slower than a
slug; I hope they've improved it by now).

     The problem with VMS isn't so much in the tools per se, but
in the lack of certain elegant concepts to which Unix programmers
are accustomed. There's only a limited notion of stdin/stdout, and
no notion whatsoever of a pipe. Version-control numbers embedded in
the OS code and actually used as part of the file name--obscene!
(It violates the fundamental, Unix-inspired concept of a file:
a file is nothing more than an ordered collection of data, to which
the system attaches no special significance other than ordering.
Besides, the old versions of files accumulate and moulder unless
you take special steps to exterminate them. I had one colleague
who actually had FILE.EXT;1001 in his directory, with all of the
previous versions as well, and didn't realize that the sysadmin's
desperate email pleadings for cleanup applied to him. We finally
got the guy fired.)

     Because pipes on VMS are a pipe dream, forget about handy
things like "sed" and "tr". This means that VMS shell scripts
(DCL procedures, I think they call them) are often more cumber-
some than equivalent Unix scripts, due to the constant need to
open temp files. (DCL scripts do allow goto's, which is a mixed
blessing.)

     Todd Merriman's statement, to the effect that Unix is a
superior development environment but VMS is a superior production
environment, has been voiced before. It's a catchy thing to say,
but I'm not so sure I agree. If anything, I'd suggest that Unix
is VASTLY superior as a development environment (except for the
debugger), while VMS is at best slightly superior as a production
environment. "Sccs," "make," "ar," et. al. are no slouches. DEC's
documentation is unquestionably superb, and always has been. But
have you seen some of the glossy stuff coming out of Summit lately?
AT&T is quickly catching up in the documentation department.

     Whatever you do, forget that Chuck Berg even mentioned Unix-
like interfaces that sit on top of VMS. Pick one or pick the other,
but don't shackle yourself to an interface with all the drawbacks
of both systems and none of the advantages of either. I admit I'm
biased in the matter, having spent the better part of a year trying
to live with Eunice. It finally got to the point where I didn't even
want to get out of bed and go to the office. I was that depressed.

     I agree with Chuck that you shouldn't encourage your client to
work across multiple environments, but human nature being what it is,
they may want to, unless they're engineers themselves and understand
concepts like engineering elegance and cleanliness of design. If their
orientation is toward business issues, you can bet they'll want to
compromise, and sling around lots of "best of both worlds" nonsense.
If you can't avoid mixing Unix and VMS in your computing environment,
at least insist on coding in C. Unix programs written in C with a
reasonable amount of concern for portability issues will generally
port to VMS without much grief. A few defensive-programming caveats,
however:

     * Unix thinks that a program which returns zero to the invocation
       environment executed successfully, and that a program which
       returns nonzero to the invocation environment executed with an
       error of some kind. The VMS convention is almost exactly the
       opposite of this. At least the VMS preprocessor has the string
       "VMS" as a built-in, so you can write:

       #ifndef VMS
       #define GOODEXIT 0
       #define BADEXIT 1
       #else
       #define GOODEXIT 1
       #define BADEXIT 0
       #endif

     * The !@$*#%! VMS C library does not have an unlink() call.
       Instead, they offer delete(), which does basically the same
       thing. So:

       #ifdef VMS
       #define unlink delete
       #endif

     * Remember that you can't count on redirecting stdio. If you
       want to have your program read input from, or send output to,
       a file, allow for optional input and output file names on the
       command line.

     * Argv[] may not point to the types of strings you expect.
       The only way to find out for sure is to look at them.

     * VMS text files typically use CR/LF as a line delimiter, and
       the standard library routines deal with this fact in various
       non-Unix ways. RTFM. Also, since the VAX architecture is based
       on 32-bit ints, it is incompatible with some PC architectures.
       Be ESPECIALLY careful with the portability implications of
       right shifts.

     You say that VMS is the favorite of some permanent staff. If
these people have tried Unix and still feel that way, you're sunk.
But if their problem is ignorance, as opposed to stupidity, insist
to management that the VMS heads write a few production programs
on Unix. They probably won't be so obdurate afterwards.

--GMH
-- 
                  * * * * * * * * * * * * * * * * * *
                  * All of your opinions are sound. *
                  *     That's all--just sound.     *
                  * * * * * * * * * * * * * * * * * *