rayl@bionov.UUCP (Ray Lillard) (03/29/89)
I am a software consultant working with a client company with lots of code developed for RSX-11. We are casting about for a new system (hardware and software) to replace the existing imbedded target system. At the same time we are also addressing the issue of a development system. My personal favorite is of course, UNIX. VMS is the favorite of some permanent staff members. I have extolled the virtues of the UNIX software environment and have been told that VMS has tools which are equally good. (They haven't been using them and the results are obvious.) What I have been shown of VMS doesn't begin to cover the UNIX tools set. It seems that the concept of a regular expression is almost completely missing from VMS. The question: Are tools available under VMS which are as powerful as YACC, LEX, AWK, SCCS, grep, make, etc... to name a few. Please email responses to me at this account or post to one of the newsgroups other than comp.os.vms. This machine doesn't carry it. Also, please be rational, I don't wish to start a VMS bashing session. Thanks to all who respond.
todd@stiatl.UUCP (Todd Merriman) (03/29/89)
In article <401@bionov.UUCP> rayl@bionov.UUCP (Ray Lillard) writes: >I am a software consultant working with a client company with lots >of code developed for RSX-11. We are casting about for a new >system (hardware and software) to replace the existing imbedded >target system......... I do cross development between Unix, VMS, and MSDOS; and I have a few opinions on the subject. I consider Unix to be a superior *development* environment, but VMS to be a superior *production* environment. The variety of tools and power of the Shell make Unix an ideal choice for technical types and programmers. The sophistication of VMS, combined with its excellent documentation and reliability make it the clear winner in production. ...!gatech!stiatl!todd Todd Merriman * 404-377-TOFU * Atlanta, GA Note: I have no idea what my employer's views on the subject are.
piet@cs.ruu.nl (Piet van Oostrum) (03/29/89)
In article <401@bionov.UUCP>, rayl@bionov (Ray Lillard) writes:
I have extolled the virtues of the UNIX software
`environment and have been told that .....
My question is: What do people generally consider to be a ``software
development environment''. Is it something like the collection of tools
that Unix has or is there much more in it, for example tools for the
specification and design parts of the software life cycle.
What experience do you have with additional tools in the Unix environment?
--
Piet van Oostrum, Dept of Computer Science, University of Utrecht
Padualaan 14, P.O. Box 80.089, 3508 TB Utrecht, The Netherlands
Telephone: +31-30-531806. piet@cs.ruu.nl (mcvax!hp4nl!ruuinf!piet)cberg@leadsv.UUCP (Charles R Berg) (03/30/89)
In article <401@bionov.UUCP> rayl@bionov.UUCP (Ray Lillard) writes: >At the same time we are also addressing the >issue of a development system. My personal favorite is >of course, UNIX. VMS is the favorite of some permanent staff >members. I am also a consultant, and have participated in developing several million lines of code on various projects, for various companies, all on VMS or RSX. (I have also developed a lot of code under UNIX, but nowhere near as much.) Whatever you do, don't encourage your client to work across multiple environments! A current client is developing 500,000 lines of code using SUNs, Masscomps, VAX's running UNIX, and primarily on VAX's running VMS. I just saw an IBM PC slip in here, too. They are using three different 'c' compilers, we're moving executables to our target environment in a.out and S-records, and beleive me, version control has been a nightmare!!! >What I have been shown of VMS doesn't begin >to cover the UNIX tools set. It seems that the concept of >a regular expression is almost completely missing from VMS. > >The question: > Are tools available under VMS which are as powerful > as YACC, LEX, AWK, SCCS, grep, make, etc... to name > a few. First of all, VMS does not have all the tools available under UNIX, but I've never lacked for a NECESSARY tool on VMS. Second, to respond to your admittedly short list: I've never had the need for YACC, LEX or AWK. DEC supplies CMS as an alternative for SCCS, and third party vendors provide many other systems for both VMS and UNIX. DEC also provides MMS as an alternative for MAKE, and has the SEARCH command instead of GREP (although yes, it does not support the UNIX concept of regular expression). Finally, if you really must have the UNIX tool environment, there are several sources of UNIX tools (including DECUS) that sit on top of VMS. I've used a few of these toolboxes and they're quite satisfactory, IMO. Your client sounds like they've run a DEC shop for awhile. I personally wouldn't try to change them. You can get the job done well in any environment you want, if you really want to get the job done well. Chuck
gm@mitisft.Convergent.COM (G.M. Harding) (03/31/89)
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. *
* * * * * * * * * * * * * * * * * *eversoler@hw-allen.UUCP (Rick Eversole) (03/31/89)
In article <401@bionov.UUCP>, rayl@bionov.UUCP (Ray Lillard) writes: > I have extolled the virtues of the UNIX software > environment and have been told that VMS has tools which are > equally good. (They haven't been using them and the results > are obvious.) What I have been shown of VMS doesn't begin > to cover the UNIX tools set. It seems that the concept of > a regular expression is almost completely missing from VMS. > > The question: > Are tools available under VMS which are as powerful > as YACC, LEX, AWK, SCCS, grep, make, etc... to name > a few. VMS has tools that can replace SCCS and make. The VMS debugger is one of the better debuggers I've used. It is still superior the Microsoft Codeview debugger on the PC. MMS (module management system) is analogous to make. CMS (code management system) is anlogous to SCCS. Also interesting in VMS are SCAN (a lexical analysis language {I've never used it}) and the performance analizer (I can not remember real name of tool but it is a profiler) As for YACC, LEX, GREP, and AWK you have a couple of choices : 1) Purchase EUNICE from Wollongong and run a UNIX shell on your VMS system. 2) Obtain the GNU versions of these excellent developement tools. I used EUNICE under VMS for about 3 years. It is very close to a complete implementation of UNIX. We've had trouble with cron, uucp, and the berkley series of TCP/IP commands (rsh and rlogin). yacc, lex, awk, sed, nroff, grep, fgrep, egrep, cc and lint all work great! You can get LINT for VMS from the Free Software Foundation (GNU) or else from IPT (Information Processing Technologies). IPT's LINT-PLUS is very good. It also can be purchased to check FORTRAN (I've no experience with the Fortran version). LINT-PLUS catches everything that UNIX LINT does plus more. LINT-PLUS has a whole lot of options to control the things it reports on. I've used LINT-PLUS for 2 years and it has saved me on several occassions. LINT-PLUS messages are a whole lot less cryptic than UNIX LINT. For the first year I would use LINT-PLUS until I had eliminated all the messages. Then I would run EUNICE's UNIX LINT (nothing new would show up). I finally started using only LINT-PLUS. Now, I'm in an Apollo environment and LINT-PLUS is not readily available here. I have to use UNIX LINT..... oh well .... VMS does not really have pipes and that can be a real pain ! It aint' cheap but EUNICE on top of VMS will give you access to the best of both worlds. While in EUNICE you can use most VMS commands. Many can even be put in a pipe. This little feature has been very helpful on several occassions. Most of the pipe work I did in EUNICE tended to be a very one-shot deal. ---------------------------------------------------------------- Rick Eversole AG Communication Systems # No association with IPT or DEC # The views expressed are soley my own and not those of the # company. # Opposing views are welcome. UUNET!zardoz!hrc!gtephx!eversoler
sommar@enea.se (Erland Sommarskog) (04/01/89)
G.M. Harding (gm@mitisft.Convergent.COM) writes: >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. With the risk of turing this into an OS war, I must object here. I fail to see what fundamental concept being violated, all I know that the multiple versions helps me sleep well at night. Just today I happenbed to press the wrong key in the editor and believing I was reading another file, I was actually writing the current file to the name of the other. (This is my own editor interface, so don't blame VMS). No problem, as soon as I had seen it. Just spawn out, and delete the newly-written file and the correct file was still there. On Unix it would have been long gone. VMS may be violating some theoretical principal, but it gives you safety. >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.) Which just goes to show that on any system you're on, you're on lose ground if you refuse to read the manual. PURGE is an essential command on VMS, as is SET DIRECTORY/VERION_LIMIT. If you think that more than one version of a file is a crime, just set the volume limit for all your directories to 1, and you have what you want. -- Erland Sommarskog - ENEA Data, Stockholm - sommar@enea.se I used to say "It could have been worse, it could have been Pepsi", then I drank a Diet Coke...
session@uncw.UUCP (Zack Sessions) (04/03/89)
As far as grep and awk are concerned, grep is handled by the DCL Command SEARCH. And the functionality of awk, though in no way similar, can be done with the optional layered product, Datatrieve. Zack Sessions
rickc@pogo.WV.TEK.COM (Rick Clements) (04/04/89)
In article <600@mitisft.Convergent.COM> gm@mitisft.Convergent.COM (G.M. Harding) writes: } * 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 It has been a few years since I have worked on VMS. But, doesn't 0 indicate not finished to VMS? A value greater than one indicates an error. Passing a 0 back from a VMS driver will crash your program (80% of the time), work ok (15%) and crash the system (5%). These are estimates based on the experience of my self on others at a previous company. } * 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. File types are a problem in VMS. There are a lot of them. The default type for a C program is different than the default type for FORTRAN. ------ All opinions are my fault. ----- -- Rick Clements (RickC@pogo.WV.TEK.COM)
peter@ficc.uu.net (Peter da Silva) (04/04/89)
On file versions: In article <4401@enea.se>, sommar@enea.se (Erland Sommarskog) writes: > VMS may be violating some theoretical principal, but it gives > you safety. In practice it gives you overflowing disks. I've used VMS, and I've found that if you don't have lots of money to spend on extra disk drives you're always PURGEing stuff. What's wrong with just making the editor keep a .bak file? Or do you REALLY want to keep all those old .EXE and .OBJ files? -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.
phil@dhw68k.cts.com (Phil Suematsu) (04/05/89)
In article <401@bionov.UUCP> rayl@bionov.UUCP (Ray Lillard) writes: > ... What I have been shown of VMS doesn't begin >to cover the UNIX tools set. It seems that the concept of >a regular expression is almost completely missing from VMS. > >The question: > Are tools available under VMS which are as powerful > as YACC, LEX, AWK, SCCS, grep, make, etc... to name > a few. > I use the GNU Yacc, GNU Lex, DECUS grep, and a public-domain make for software development under VAX/VMS. The GNU software has distribution restrictions. If you distribute a binary that includes any of GNU's code, you have to distribute the source to generate the binary. DEC distributes a source control system called CMS and a 'make' type program called MMS. VMS has routines for terminal independent I/O (what you might use curses for under Unix). I also have the Zmodem file transfer programs sz and rz and the LZW compress programs from Unix working under VMS. I can't easily distribute things on tape, but I can easily distribute source code by MS-DOS diskettes if you are interested in the utilities I have that may be freely distributed (Yacc, Lex, Grep, Make). In summary, yes, you can have your Make and EDT it too. -----------------+------------------------------------------------------ Phil Suematsu | InterNet: phil@dhw68k.cts.com Optical Research | or uucp: ...{trwrb,hplabs}!felix!dhw68k!phil Associates | or Work: (818) 795-9101 or Home: (714) 633-0876 -- -----------------+------------------------------------------------------ Phil Suematsu | InterNet: phil@dhw68k.cts.com or phil@turnkey.tcc.com Optical Research | or uucp: ...{trwrb,hplabs}!felix!dhw68k!phil Associates | or Work: (818) 795-9101 or Home: (714) 633-0876
gm@mitisft.Convergent.COM (G.M. Harding) (04/07/89)
In article <7036@pogo.WV.TEK.COM> rickc@pogo.WV.TEK.COM (Rick Clements) writes: > But, doesn't 0 indicate > not finished to VMS? A value greater than one indicates an error. > Passing a 0 back from a VMS driver will crash your program (80% of the > time), work ok (15%) and crash the system (5%). These are estimates > based on the experience of my self on others at a previous company. The last time I used VMS (4.3? 4.4? Am I thinking of some other software product?) code ported from Unix with a standard "return (0)" at the end of main() would cause VMS to display a particularly unaesthetic error message on the screen at process termination. The system did not, however, crash or otherwise behave abnormally. Perhaps zero has the connotation you mention at the driver level, but I don't think such is the case at the application level. The way I discovered what was happening was peculiar: I noticed that the VMS termination-error message went away if my program had an internal error! In that case, it would return 1 from main(), which VMS thought was just fine. The Unix convention on process-termination values makes a lot of sense. Think about it: There are many flavors of failure, but there's only one variety of success, namely, the complete kind. So, the Unix shell correlates the process-termination value with the question: Were there errors? If the termination value is logically TRUE, the answer is "yes"; otherwise, "no." > File types are a problem in VMS. There are a lot of them. The default > type for a C program is different than the default type for FORTRAN. This underscores the point I was making in my original reply to the fellow who asked for an OS comparison. The system has no business knowing (or thinking it knows) what's in my files. When OS writers try to do cute things like that, they throw device independence out the window. (Notice that nobody has ever accused VMS of being based on the spirit of device independence. Ever try to mount a tape on VMS?) -- G. M. Harding /* * * * * * * * * * * * * * * * * * * * * * POB 4142 Santa Clara CA 95054 * Opinions expressed on Usenet are sound. * Work: (408)-435-3294 * That's all--just sound. * ...{uunet,pyramid}!ctnews!gm * * * * * * * * * * * * * * * * * * * * * */
bobd@zaphod.UUCP (Bob Dalgleish) (04/12/89)
The major difference between Un*x and V*S is that it is EASY to write your own tools in Un*x. The use of pipes means that homomorphic transformations can be applied one after the other until you get the desired result: read this as functional decomposition. When pipes are expensive, inconvenient, or awkward to use, the software developers spend less time writing simple tools to help them in their work and more time doing things by hand or using the supplied tools. There is no argument that the programs available on V*S are better or worse than those on Un*x. The argument is whether it is easy to put several tools together to make one that does the job that *I* want done right now. Remember, Man is the tool-MAKING animal. Many other animals use tools (birds, monkeys, otters, etc.). Spending a small time to put tools into one's bag of tricks makes one much more effective as a software developer. The shells that run on V*S cannot hide all of the differences. The architecture of V*S assumes monolithic applications with well-defined interfaces that start up, run for a (relatively) long time, and get ready for the next request; Un*x assumes small applications that come and go as they please, creating and destroying files readily. Consequently, Un*x shells run slowly and awkwardly, destroying any advantage that might have been gained by making your own tools. Any argument that writing a C program to more efficiently do the job is absurd; the expensive part of the process is the programmer time, not the machine time. It takes me 5 minutes to design, implement and test a simple three stage shell script to do some straight-forward analysis; it takes me one day to design, write, and test the same code in C. With that trade-off, which do you think I would prefer? How about you? -- --[ It is good to be back in the saddle ]-- Bob Dalgleish bobd@zaphod.UUCP