jay@hp-pcd.UUCP (06/12/84)
Case in point: How many VMS ports to other CPUs/architectures compared to Unix ports? I rest my case. hp-pcd!jay
sean@oddjob.UChicago.UUCP (Sean Casey) (06/14/84)
A discussion arose the other day about the relative advantages of running Unix vs. VMS on a Vax 11/750. I'm interested in knowing the consensus among net users (ignoring obvious selection effects.) Arguments in favor of VMS were... o FORTRAN runs faster under VMS (I don't know how FORTRAN under VMS compares to C under Unix??) o VMS runs faster than Unix in a multiuser environment. o One can always run a Unix emulator under VMS for those users who prefer Unix. (Why is there no VMS emulator under Unix?) In favor of Unix... o A nearby SUN workstation running Unix would be easier to interface if the Vax ran Unix too. ( What is the status of VMS to Unix communications?) o Most software would be developed by students who would rather use C than FORTRAN. ( C scores high as a structured language.) o Unix is such fun! I would appreciate hard numbers on how VMS and Unix compare along with suggestions on the criterion for choosing one system over another. Please reply via mail and I will post the results to the net. Sean Casey || University of Chicago ...!ihnp4!oddjob!sean || Dept of Astronomy and Astrophysics
mcdermot@unmvax.UUCP (06/14/84)
One question Sean Casey asked about Unix vs. VMS was speed of VMS
FORTRAN against Unix C. I did just such a comparison some time ago
comparing machines with 10 users each (the unix was 4.2BSD) and I
found little difference in run time of compute oriented jobs.
I/O, however, is quite a different story: I ran these little programs
and found the C to be about 10 times faster than the FORTRAN! This just
points out how poor FORTRAN's I/O system is, though, and was primarily
used to convince some friends to get a unix machine (they do a lot of
I/O so this was really important).
program iobench
do 111 i=1,65000
write(6,61)'aaaa'
61 format(a4)
111 continue
end
main(){
register int i;
for(i=1;i<=65000;i++)
printf("%s\n","aaaa");
}
Hope this helps,
john
--
John McDermott {gatech|ucbvax|convex}!unmvax!mcdermot
Univ of NM W (505) 277-4650
Albuquerque, NM 87131 H (505) 255-7796gwyn@brl-vgr.ARPA (Doug Gwyn ) (06/17/84)
I think you got the bit about VMS emulators on UNIX wrong. Clearly, if VMS has a larger software base (as you claim), then there would be motivation for VMS-on-UNIX, but this is the opposite of the argument you gave for there not being one. VMS doesn't matter in the big picture; it runs only on not- very-cost-competitive DEC VAX processors. UNIX runs practically everywhere. If Fortran is your bag, certainly there are fast Fortrans available on various vendors' UNIX systems. Shop around.
cbspt002@abnjh.UUCP (06/18/84)
>How many VMS ports to other CPUs/architectures compared to Unix >ports? Two (VAX and MicroVAX I). By the fall the answer will be four (add VAX 11/790 and MicroVAX II). While this doesn't compare to the number of so-called Unix 'ports' (many of which have compatibility problems), I can bet my life that anything that runs on one VAX/VMS system will run unaltered on any other (without a recompile, even). This is not my experience with Unix, nor should such an expectation be rational, since an operating system, to be effective (*fast*, reliable, make full use of the hardware, etc.) must be closely knit to the hardware. And VMS has EDT.
chip@t4test.UUCP (06/18/84)
=== REFERENCED ARTICLE =============================================
From: gwyn@brl-vgr.ARPA (Doug Gwyn )
I think you got the bit about VMS emulators on UNIX wrong.
Clearly, if VMS has a larger software base (as you claim),
then there would be motivation for VMS-on-UNIX, but this is
the opposite of the argument you gave for there not being one.
VMS doesn't matter in the big picture; it runs only on not-
very-cost-competitive DEC VAX processors. UNIX runs practically
everywhere. If Fortran is your bag, certainly there are fast
Fortrans available on various vendors' UNIX systems. Shop around.
====================================================================
In my original followup I tried to make the point that in nearly all
applications, computers are purchased to run specific software which
is targeted at specific needs. I also hoped to convey that these
needs must be considered before any others a potential machine or
operating system may be considered. I also aired my opinion that
VMS has a wider software base than Unix--I don't have any firm
statistics to back that up.
A premise which I took for granted and maybe I shouldn't have was
that it always takes some degree of work to port software into an
emulator environment. At least, that is what our experiences say.
As a result, I reached the conclusion that there is a greater need
to be able to run in a native VMS environment than a native Unix
environment.
Combine this conclusion with the idea that it is much nicer for
the user to talk to Unix than VMS, you come up with explanation
why there is need for a Unix emulator to run under VMS, but not
vice versa.
The one exception to the above would be that the amount of software
which requires a VMS environment is minimal, and therefore its
porting into a VMS-emulator-under-Unix would not be too dificult.
In this case one would be willing to deal with the pain of the
portation to gain the benefits of true Unix.
If the production of Intel's microprocessors matters "in the
big picture," then VMS does as well. VMS is a prerequisite to
our ability to develop component tests. If you would like some
additional examples where VMS matters, tune in net.physics. There
are some folks over there knocking down Unix for their specific
applications, one of which is the ability to run Fortran.
Again, it is entirely reasonable to get into theoretical comparisons
of VMS against Unix. (I'd vote for Unix.) But when it comes to
shelling out the bucks, you'd better look at what you want that
computer to do first.
--
Chip Rosenthal, Intel/Santa Clara
{idi|intelca|icalqa|imcgpe|kremvax|qubix|ucscc}!t4test!{chip|news}
Any resemblance between the author and persons
living or dead is entirely coincidental.rbbb@RICE.ARPA (06/19/84)
From: David Chase <rbbb@RICE.ARPA>
I wasn't going to CC info-unix, but that seems to be the thing to do,
sooo...
VMS over UNIX
The fortran is better; it is mostly correct, doesn't explode on
correct code, and is usually faster. It also provides better error
messages.
I think the Pascal is better, but I haven't compared the two
myself (I hate Pascal). The Pascal jocks want me to be sure that VMS
Pascal is under maintenance, etc etc, and they seem to use it more than
the Pascal that comes with Berkeley Unix, so I guess they like it better.
If you use macro-assemblers, there is none for unix, and MACRO-32
is fairly feature-filled. I wrote the back end of a BCPL compiler in
MACRO-32 (OCODE --> assembly language).
When the next minor version of VMS comes out, your programs will
still run. When the next major version of VMS comes out, your programs
will still run. We are still running (under 3.6) programs that were
linked under 2.5, and these programs are linked against a user-written
library full of change-mode vectors. Of course, the library is installed
as a shareable image, so it has been changed many times.
With VMS, you can do all of the things that are hard under unix;
you can do mutual exclusion, you can do shared memory, you can do
concurrent io. You can single-step debug your kernel-mode code, if you so
chose. You can reload device drivers without rebooting the stinking
operating system. You get ISAM files, if you want them.
VMS is easier to manage. You have much more control over
resources than under Unix. Batch queues, for instance.
VMS tends to get more performance out of its hardware, through
clustering, asynchronous IO, and good paging. These things can be tuned
for a particular installation, though they can also be mistuned.
If I write something under VMS, and decide I maybe want to sell it
or give it away, I don't have a dozen lawyers breathing down my neck.
Shareable images and shareable libraries are pretty fun; shared
programs (like shared text) for the images, and shared libraries (like
nothing available in Unix) for shared text and swift and easy software
updates (change the library, but don't need to relink).
UNIX over VMS
Most of the VMS "user interface" is abysmal. We're talking EDT
for an editor and DCL for a "command language interpreter". No make.
No awk. DCL scripts can be almost bearable, and you can get at all sorts
of neato information from DCL, but there's no IF, no DO, no CASE; only
GOTO. Perhaps there DEC program products out there that make life
bearable; the people here chose the path of writing a unix emulator,
rather than porting the selected useful programs.
Certain operations are slow under VMS; some file io and process
creation are two.
Special VMS hates:
I can run my terminal (it's a file, right?), but to get its
protection I have to do a (from DCL) F$GETDVI("TT", "VPROT") rather than
whatever I might do for a real file. This sucks a bit.
There is no explicit way to make links, but I can by making the
source directory non-writeable, then renaming into the target directory.
This allows everything BUT a single node directory loop, which is
explicitly verboten for some bizarre reason.
"Concealed devices" may only be one directory level deeper than a
real device, and there is no way to "SET DEF" to the root of the concealed
device and have it still act like a device.
Although there appears to be some sort of terminal-independent
library for VMS, many or all of the screen-oriented programs don't seem to
use it.
Networks?? With DECNET you can speak to any other DEC OS around.
Who would ever want to do more???? (Actually, there do seem to be
provisions for speaking SNA and X.25, but I'm not terribly familiar with
them).
File names are TOO short (N.B. this goes away with VMS version 4,
up to 39.39.version number, I think.)
Special VMS loves:
BACKUP is really ace, though it has a fairly steep learning curve.
Much more function than tar. (Not as hard to learn as "find", because I
have wanted to use both, and I still haven't figured out "find".) This
may not seem like much, until you lose some important data. I can do
BACKUPs on an active file system.
When I say "help", I usually get help, and there appears to be a
uniform help interface across DCL and many commands.
The RMS file syntax, though grotesque, is often used to provide
more power than I get from the Unix shell expansion syntax. The most
useful feature for me is the ability to say "all files in this directory tree
that look like this", as in "[...]*.obj.*". Someone could add this to
their favorite shell without too much damage, I think. I could do this
with a find, but as I said before, I haven't been able to master find.
I can add pagefiles and swapfiles while the system is running, and
I need not scratch a disk to expand them (N.B. this depends very much on
the availability of contiguous space for creation of these files).
I can read and write ANSI label tapes (remember ANSI?? you know,
"ANSI: consider it a standard...") so that I can communicate with other people
running practically anything but Unix.
Logical names: They're great, period. We hacked unix "make" to
treat environment variables in the same way.
Things WORK. No surprises (except for those mentioned above).
The options to commands have names that I can remember.
Special Unix hates:
A stinking minor version change breaks the whole world. Already
there are two different Unixes.
Unix encourages C, and that is bad. C is just assembly language
with pretensions.
If I miss a keystroke, I type "rm *>CKP". This is very bad.
Often things don't work. The "bugs" section on every manual page
is a real loser, since no one seems to fix things, and if they did, that
might break someone's program that depends on the bug.
General impressions: probably if you have a gang of software developer
sort of guys, they will want to run Unix because "it makes them more
productive". I expect that Unix + make + awk + emacs (you can afford it)
will allow programmers to hack out more code than they would under VMS,
but they might not need to hack out so much code under VMS. This depends
upon the nature of the code being written. I snicker every time I see
some plea for ISAM files or mutual exclusion or shared memory on the net.
Once an application is written, I expect that the previous user interface
(shell or DCL) will be hidden, and that the quality of the OS underneath
will be more important. From this point of view I think that VMS is much
better (I know, I know, QIO takes a million parameters, but most of them
are optional, and it usually does the right thing if you leave them
alone). Imagine this situation; I have invested zillions of dollars in an
application (running under 4.1) that has become essential, and it won't run
under 4.2. This can also happen in VMS land, but is much less likely.
In an educational environment, there are again tradeoffs. Educational
machines here have had bad problems with severe load and security
doodling; I'm not sure that VMS would help, but I suspect that it could.
Many of the neato-utilities for Unix could be rewritten for VMS (for
instance, one of the programming projects for a course here was "make"
written in Pascal).
I am very very happy with emulators; we run Phoenix (written here) and I
freely switch from one interface to the other (to the utter disgust of the
Unix Zealots around here). I have learned to use EDT for the quickie
editing jobs, and emacs for the more involved ones. We wrote IP and UDP
for VMS, so we can communicate in a primitive fashion over the ethernet
(I'm sorry, but UUCP is just a little too mickey mouse for me. I've had
to use it, and I hate it). Much of this software is available, or soon
becoming available.
For some background on why I say what I do; I have managed a 780 running
VMS+Phoenix for over two years now, and I do program development on
whatever is available. Both the VMS and Unix have been heavily sanitized
with local scripts, com files, and programs; I am nearly helpless in
vanilla Unix (not so for VMS only because I am manager and MUST know how
to work in raw VMS; all of our users are non-portable). In a pinch I fix
things on the "real" Unix machines. I also maintain emacs across Phoenix,
4.1, and SUN/BSD4.2. In my much darker past I used cards on an ITEL (now
NASCO) AS/6 running MVS, later SPF. Did you know that you can pipe the
output of one JCL job step to the input of another? (Chew on that).
drccbspt002@abnjh.UUCP (Marc E. Kenig ) (06/19/84)
<...> >Clearly, if VMS has a larger software base (as you claim), >then there would be motivation for VMS-on-UNIX, but this is >the opposite of the argument you gave for there not being one. The point is also moot, since many applications which run on VMS simply couldn't run, or run reaching reasonable efficiency, on an emulated VMS. (There is no 'if' about VMS having a larger applications base, for the time being*) Many VMS applications (reasonably) rely on VMS features, - virtual memory (try running SAS on UNIX:-)) - RMS record management (why reinvent the wheel for disk storage schemes?) - record locking primitives(ditto) - Logical OS symbols, Star coupler support, multi-langauge single-vendor SUPPORT - real-time performance (I dont have any illusions that VMS is a real-time OS but it sure beats UNIX with a stick.) >UNIX runs practically everywhere. If Fortran is your bag, certainly there are >fast Fortrans available on various vendors' UNIX systems. Shop around. "various vendors"? Excuse me, but many of us in the real world don't have the option to "shop around". Managerial-types can get real antsy when it comes to multi-vendor, non-"big name" (ie,IBM, DEC, etc.) systems. I think Unix *should* be better, and of the two it is the OS w/a future. For an interesting view see IEEE 'Computer' June 1984, "Standards Can Help Us", C. Gordon Bell page 76.
cwc@uw-june (Winnie Chow) (06/20/84)
/**/ > Unix encourages C, which is bad. C is just assembly language > with pretensions! Blasphemy! What's your pleasure? Basic? -- ...!tektronix!uw-beaver!uw-june!cwc
guy@rlgvax.UUCP (Guy Harris) (06/20/84)
> >How many VMS ports to other CPUs/architectures compared to Unix > >ports? > Two (VAX and MicroVAX I). By the fall the answer will be four (add > VAX 11/790 and MicroVAX II). How is the VAX-11/790 a different architecture? How are the MicroVAXes different architectures (except for having fewer instructions than the other VAXes)? The correct answer is "zero"; VMS hasn't been ported to anything not running the MicroVAX instruction set or some superset. > While this doesn't compare to the number of so-called Unix 'ports' (many > of which have compatibility problems), I can bet my life that anything that > runs on one VAX/VMS system will run unaltered on any other (without a > recompile, even). This is not my experience with Unix, nor should such an > expectation be rational, Such an expectation would not be rational if you include the "without a recompile" clause, because binary code for a PDP-11 doesn't run on a M68000 unless you write a simulator. (By the way, if you write code that doesn't adhere to the VAX-11 architectural standard - as was done *for UNIX* (the "printf" assembly-language implementation) - you can write something that runs on one VAX/VMS system and will not run unaltered on some others.) > since an operating system, to be effective (*fast*, reliable, make full use > of the hardware, etc.) must be closely knit to the hardware. Closely knit in what sense? Some UNIX ports aren't tuned for their hardware. Some are. Do you consider UNIX on a PDP-11 ineffective? Do you consider it ineffective on a VAX-11? A SUN workstation? Would you care to prove your point by writing an OS for the SUN workstation (say) which is sufficiently faster, and sufficiently more reliable, and which makes more complete use of the hardware that it shows UNIX to be ineffective? Please provide a detailed justification of why UNIX cannot be knit closely enough to the hardware to be effective by your criteria. > And VMS has EDT. So? UNIX has "vi" and EMACS, to mention two editors thought of very highly by their devotees. Guy Harris {seismo,ihnp4,allegra}!rlgvax!guy
guy@rlgvax.UUCP (Guy Harris) (06/20/84)
> Many VMS applications (reasonably) rely on VMS features, > - virtual memory (try running SAS on UNIX:-)) You may not be able to shop around, but if you do you'll find that virtual memory isn't a "VMS feature" - virtual memory UNIXes do exist, even though AT&T hasn't released theirs yet. > I think Unix *should* be better, and of the two it is the OS w/a future. > For an interesting view see IEEE 'Computer' June 1984, "Standards Can Help > Us", C. Gordon Bell page 76. Yes, UNIX can and should be better. (And a lot of the deficiencies you mention have been fixed in some versions of UNIX.) Like it or not, it's being used for a wider range of applications that it was originally used for; some may complain about adding functionality to it, but that's life. I agree; Bell's paper is worth reading. Guy Harris {seismo,ihnp4,allegra}!rlgvax!guy
chip@t4test.UUCP (Chip Rosenthal) (06/21/84)
=== REFERENCED ARTICLE =============================================
From: sean@oddjob.UChicago.UUCP (Sean Casey)
A discussion arose the other day about the relative advantages
of running Unix vs. VMS on a Vax 11/750. I'm interested in
knowing the consensus among net users (ignoring obvious selection
effects.)
Arguments in favor of VMS were...
o FORTRAN runs faster under VMS
(I don't know how FORTRAN under VMS compares to C under
Unix??)
o VMS runs faster than Unix in a multiuser environment.
o One can always run a Unix emulator under VMS for
those users who prefer Unix.
(Why is there no VMS emulator under Unix?)
====================================================================
People buy computers to run software, not to play with the operating
system. (While I like to play, I don't shell out the bucks.) There is
a hell of a lot of software developed to run in a VMS environment. All
of the test program compilers we use are VMS based. Therefore, in spite
of which runs faster, is nicer, etc. we *need* VMS. However, Unix is
certainly a very nice environment for development, so we are running
Eunice in an attempt to get the best of both worlds.
If Unix had the developed software base which VMS does, then maybe there
would be a call for VMS emulators under Unix. Maybe someday Unix will
it. From what I hear from our test vendors, the world is beginning to
discover Unix. Until that time VMS will be a requirement for one and
only one reason: it is the only thing which does the job we need to do.
Until you address this, you can't even begin to address the other factors.
--
Chip Rosenthal, Intel/Santa Clara
{idi|intelca|icalqa|imcgpe|kremvax|qubix|ucscc}!t4test!{chip|news}dyer@dec-vaxuum.UUCP (06/21/84)
How do Unix and VMS compare?___________________________________________________ David Chase (rbbb@RICE.ARPA) sent in a rather lengthy comparison of VMS and Unix. I'd like to add a few things, speaking as a heavy VMS user in my capacity as a programmer/analyst at DEC. > No make. No awk....Perhaps there [are] DEC program products out there that > make life bearable;... There certainly are. There's MMS (Module Management System), which is essentially make with some VMS/DCL features added. It's a DEC product. I'm not at all familiar with awk but I believe someone's gotten it to run on VMS. > I expect that Unix + make + awk + emacs (you can afford it) will allow pro- > grammers to hack out more code than they would under VMS,... MMS (make) has certainly made life easier for me on VMS. If the Emacs you're referring to is the James Gosling Emacs, Unipress Software - the place you get the Unix version - also sells a VMS version. > Many of the neato-utilities for Unix could be rewritten for VMS... Definitely true; net.sources is my favorite newsgroup, and I've had great success getting things to run on VMS using VAX C. Also, a good number of Unix utilities have been made to run on VMS - as well as other DEC operating systems - by Martin Minow & company. <_Jym_> ._________________________________________________________. .__! Jym Dyer <> Software Craftsworker for DEC <> Nashua, NH !__. .__! Arpanet: dyer%vaxuum.DEC@DECWRL.ARPA <> E-Net: VAXUUM::DYER !__. __! Usenet: ...{allegra|decvax|ucbvax}!decwrl!dec-rhea!dec-vaxuum!dyer !__ NOTE: Statements provided here are based on my own beliefs, and not necessar- ily those of |d|i|g|i|t|a|l| Equipment Corporation.
henry@utzoo.UUCP (Henry Spencer) (06/22/84)
> - virtual memory (try running SAS on UNIX:-))
I believe the SAS people are busy putting up SAS on Unix right now.
Given the right hardware, and some intelligent Unix porters, Unix has
no problem with virtual memory.
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henryhenry@utzoo.UUCP (Henry Spencer) (06/22/84)
> A stinking minor version change breaks the whole world. Already > there are two different Unixes. No, there aren't. There is Unix, and there is a hodge-podge from Berkeley that calls itself Unix but isn't. Don't be taken in by misleading advertising. At Usenix I wore (part of the time) a button saying "4.2BSD does everything UNIX does, only differently.". > Often things don't work. The "bugs" section on every manual page > is a real loser, since no one seems to fix things, and if they did, that > might break someone's program that depends on the bug. The difference is that VMS doesn't bother documenting the bugs. As for "no one seems to fix things", this is sometimes true of DEC as well. > ....... Imagine this situation; I have invested zillions of dollars in an > application (running under 4.1) that has become essential, and it won't run > under 4.2. This can also happen in VMS land, but is much less likely. If you try to port things from a more-or-less Unix (e.g. 4.1) to a system that claims to be Unix but isn't (4.2), of course you're going to run into trouble. Stuff written for V7 will run on damn near any Unix in existence, across an immense spectrum of hardware. I speak from some experience on this; U of T and its friends are *not* all-Dec shops by any stretch of the imagination. > ................................................... We wrote IP and UDP > for VMS, so we can communicate in a primitive fashion over the ethernet > (I'm sorry, but UUCP is just a little too mickey mouse for me. I've had > to use it, and I hate it). Much of this software is available, or soon > becoming available. There are any number of people selling non-primitive Ethernet software for Unix already. Writing your own for Unix is unnecessary. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
ignatz@ihuxx.UUCP (Dave Ihnat, Chicago, IL) (06/22/84)
I'm sorry to add to the verbiage, but there are a couple of items which Dave has obviously misunderstood in his defense of VMS over UNIX, and that I think are quite important to keep in mind in this burgeoning Unix milieu. >VMS tends to get more performance out of its hardware, through >clustering, asynchronous IO, and good paging. These things can be tuned >for a particular installation, though they can also be mistuned. This is quite true. What you're missing is the very important fact that everyone involved in development of standard Unix is quite aware that, if they wrote machine-specific code, they could usually get gobs of performance improvements on their machine. And only on it. Unix can be moved across machines with architectures and capabilities as widely differing as an IBM-PC, a VAX 11/780, and a Univax 1180. True, porting to a new machine is not something you give to a summer employee; but just try to "port", say, Univax Exec 32 to a Sun workstation. The premise under which people have been willing to get less horsepower from their hardware has been Xfold: First, hardware is getting steadily more powerful for less money; this trend is certain to continue. Secondly, they now have a common environment for their internal development, no matter what mix of machines they have, for new employees--all those Unix-trained college graduates coming out--and for products which simply require a "Unix environment". All of these concerns outweigh eking a few more kips from your tired old CPU. >If I write something under VMS, and decide I maybe want to sell it >or give it away, I don't have a dozen lawyers breathing down my neck. No one else does, either, as long as you don't carelessly include proprietary programs in your application. (Note that this does not affect inclusion of object libraries) I really don't see how this applies in this instance. >A stinking minor version change breaks the whole world. Already >there are two different Unixes. What do you mean already? There are more than two Unixes, friend, and this can directly be traced to Berkeley's door. I won't say they were totally wrong to modify v32 so heavily, and encourage its proliferation, since BTL didn't/couldn't do so with their Unix; but it certainly didn't help. Unix is *not* a mature OS. The final form of the kernel won't be solidified for some time, despite what they say about System 5 R2. Minor changes don't break the world; major ones do. Before you tout VMS's stability, go back to the time IT was only about 5 years out the door, and see what it's history was like, even with a single source. >Unix encourages C, and that is bad. C is just assembly language >with pretensions. This is the most incredible statement I've ever seen. OF COURSE 'C' is just an assembly language replacement. A PORTABLE assembly language replacement. For at least the 12 years I've been in the field, I've heard various prophets harking their various high-level languages, and finally announcing the death of assembly language. It hasn't happened yet, and won't happen, for there ARE cases where you need tight, efficient code. Yet, using 'C', it IS possible to do almost all of those horrible jobs that formerly required assembler--drivers, interrupt handlers, etc.--and do it with a portable language that gives an efficiency close enough to the native assembler that many are willing to accept the penalty for--you guessed it--the portability. Use some high-level language when you need the power it provides; use 'C' in lieu of assembler when you need tight, fast code. C will be around long after Unix is used as an obsolete example in beginning CS courses. There were several other items to which I took exception--for instance, criticism of individual commands, or bugginess of commands--which should, rightly, be compared to both command and OS bugs on VMS combined, since so much of a "traditional" OS has been moved from the kernel to external commands in Unix. But in general, I want to emphasize that Unix is immature, and has growing pains. But the quite different concepts embodied in Unix make comparing it with mature, traditional OS's a task that should be undertaken with more care than, say, comparint PR1MOS IV with VMS... All opinions and statements expressed herein are solely mine, and in no way may be construed as reflecting the official or unofficial opinions or attitudes of either my contractee, or my employer. Dave Ihnat ihuxx!ignatz
SMH@SRI-KL.ARPA (06/25/84)
From: "Scott M. Hinnrichs" <SMH@SRI-KL.ARPA> Where is it written that the VAX is the most cost effective machine? And, if it is, how long will it be so? Where will you go when the VAX upgrade path is too expensive to follow? The rumored Venus is supposed to be 3-4 times a vax at ~twice the cost. Where will you be with VMS when DEC cancels development of the VAX line, a la` Jupiter, in favor of it's newest architecture? Will VMS follow TOPS20? Aren't you tired of being locked into one vender? Wouldn't you like them to work a little harder for their market niche? Just a few thoughts to keep in mind as you plan your DP future. scott -------
mark@umcp-cs.UUCP (06/26/84)
I too have formed the opinion that there is more software available
under VMS than Unix. I think this is based on my reading of Computerworld,
which tends of lots of ads for software under VMS, almost nothing
for software under Unix.
--
Spoken: Mark Weiser ARPA: mark@maryland
CSNet: mark@umcp-cs UUCP: {seismo,allegra}!umcp-cs!markdan@idis.UUCP (06/27/84)
Re: the notion that more software must be available for VMS than for UNIX because there are more advertisements for VMS software. VMS software is apparently more profitable than UNIX software. There are more VMS VAXES than UNIX VAXES, but there are far more UNIX machines than VMS machines. It seems that software publishers can get away with charging a lot more for VMS software than for UNIX software. Why? Some possible explanations: 1) Organizations that use VMS are used to spending more for the same functionality and performance. Universities are cheap. 2) It is more difficult to make things work on VMS. Therefore there is less potential competition. 3) VMS users tend to be end users while UNIX users tend to be capable of rolling their own applications. VMS users need more hand holding. 4) UNIX software tools and the flexible UNIX user-system interface reduce the need for expensive software. The rigid user-system interfaces one finds in commercial operating systems like VMS creates an opportunity for the commercial software developer.
mark@elsie.UUCP (06/28/84)
<> David Chase (followed by others) have been involved in UNIX (AT&T Bell Labs Trademark) vs DEC's VMS OS (DEC Trademark). I'll try not to go over old ground (bless you, 'e' option), but there are a few points I would like to make. > When the next minor version of VMS comes out, your programs will >still run. When the next major version of VMS comes out, your programs >will still run. We are still running (under 3.6) programs that were >linked under 2.5, and these programs are linked against a user-written >library full of change-mode vectors. Of course, the library is installed >as a shareable image, so it has been changed many times. ... > A stinking minor version change breaks the whole world. Already >there are two different Unixes. I.e., VMS is backward compatible. This means that every design glitch in the original version of VSM must be carried forward forever, or until DEC decides to no longer support VMS. This also means that if you get sloppy and lose your source code VMS will cover for you until the stray gamma ray comes along and zapps you. This also means that if new idea comes along (e.g. a new filing system, or object code format) you may not be able to install it unless backward compatibility can be maintained. Eventually things become set in concrete and you're left with an obsolete dinosaur. I maintain that losing source or bit tiddeling object code (so you have no source) is a major programming sin. One should recompile ones programs regularly (at least those installed system wide) to be sure they still compile and run. If, every few years, a new version of the OS comes out that requires recompiling or relinking of all code, and *THAT RESULTS IN A MAJOR IMPROVEMENT IN SYSTEM PREFORMANCE*, then I for one am willing to spend the few hours of compile time and the few weeks of system shakedown to bring the new system up. Of course then, we're not a bank. > Unix encourages C, and that is bad. C is just assembly language >with pretensions. This is the only truly ridiculous statement in Mr. Chase's entire article. Yes, C is a glorified assembler. A device independent assembler. And, I believe, most compilers, at some point, produce assembly code before churning out machine code. C is also highly portable, concise, and powerful. It ain't perfect, to be sure, but it's better than most. > If I miss a keystroke, I type "rm *>CKP". This is very bad. Amen. But isn't it possible to miss a key stroke and do something very bad in VMS also. Surely some new user must have figured out a way by now :-) Now, M. Kenig writes: >If Unix had more machine specific code, it would be more difficult to port. >Unix "can be moved across machines with architectures and capabilities" >easily because it seems the people who move it CHOSE TO IGNORE THE UNIQUE >CAPABILITIES and ARCHITECTURES OF THOSE MACHINES. Case in point: the VAX. >Ignore the FPA and the Virtual memory and what have you got? Right, a >PDP-11/40. Whoopee! It's even more cruel to do this to a larger machine >like a Cray. Says Unix-porter, "Nothing easier if we ignore the vectorizing." >Giving the power of an 11/70 to an IBM-PC is a noble thing, giving it to a >VAX reminds me of a Ben Franklin quote: "Calling a steer a 'bull' is a >compliment; he's grateful for the compliment, but he'd rather have restored >what's rightfully his". Bunk. There are good ports and bad ports. A new machine will usually come up with the minimum possible UNIX. Remember U/32? With time the OS for that system will improve. This is true of all (most?) OS's. Look at 4.2 bsd; compare 2.0 VMS with the latest version. With C you can take advantage of machine architectures and maintain portability with the use of #ifdefs. I.e.: #ifdef VAX ...vax assembler here via the asm() mechanism; e.g. mov3() #else ...portable C code here.. #endif But, a system intimately tied to VMS, or any other proprietory OS, will be forced to run only on DEC machines running VMS. That is, after all, on of the reasons they give you VMS when you buy a VAX. They want to make sure your next computer will also be a VAX (or something compatible). That's just good business, and that's also one reason DEC used to fight you when you tried to bring UNIX up on one of their machines (that was back in the dark ages and is certainly no longer true). >All opinions and statements expressed herein are solely mine, and in >no way may be construed as reflecting the official or unofficial >opinions or attitudes of either my contractee, or my employer. Ditto. -- Mark J. Miller NIH/NCI/DCE/LEC UUCP: decvax!harpo!seismo!umcp-cs!elsie!mark Phone: (301) 496-5688
cjl@iuvax.UUCP (06/29/84)
>>Unix encourages C, and that is bad. C is just assembly language >>with pretensions. >it--the portability. Use some high-level language when you need the >power it provides; use 'C' in lieu of assembler when you need tight, >fast code. C will be around long after Unix is used as an obsolete >example in beginning CS courses. As part of programming tools, C and Pascal are designed with sharp different point of views. C emphasizes on flexibility. Whenever there is a conflict between reliability and flexibility, C always sacrifices reliability. In contrast, Pascal sacrifices flexibility to achieve the reliability whenever there is a conflict. Both languages are OLD, full of shortcomings. The book written by people from Bell Labs : Feuer : "Comparing and Accessing Programming Languages- Ada,C,Pascal" explains the detail. It is worth reading. Although C is more successful than Pascal as a production language because of its flexibility, it doesn't mean C is a good one even. Quoted from the above book: "The programming style by C (e.g. side- effect in expression, use of pointers, interchangeable use of array and pointers) makes programs harder to verify."....thus to read, to develop, and to maintain. Today C represents a bad example from software engineering point of view. Its prolifiration will be paied off by the high cost of software production and maintenance. Pascal, though very successful in theory, looks like a toy language from today's point of view. It cannot meet the challenge of modern, wide, and large software applications. Even programming in small, it cannot support the most important programming concept today - MODULARITY. As an educator, we teach Pascal basically. C would only be reluctantly taught in Operating Systems class with a lot of warning. We already start the use of Modula-2 and Ada. The flexibility of C can be achieved by the small Modula-2 and big Ada. Personally, I hope the industry can avoid the use of C at all by switching to the new languages with courage. CJL (CSNet : cjl@Indiana@CSNet-Relay)
graceh@linus.UUCP (Grace L. Hammonds) (07/07/84)
I missed the original (I gather somewhat lengthy) comparison.
Would someone please mail it to me?
Thanks,
--
--Grace Hammonds
{allegra,genrad,ihnp4,utzoo,philabs,uw-beaver}!linus!graceh (UUCP)
linus!graceh@MITRE-BEDFORD (ARPA)stern@bnl.UUCP (Eric Stern) (07/15/84)
People seem to have misguided perceptions of VMS users and have come up with some pretty funny ideas of why VMS software may cost more than Unix software. I suspect that the reason VMS software costs more than UNIX software is that VMS software if of course only written for Vaxen, while UNIX software is written for any UNIX machine. Some UNIX machines are quite inexpensive these days, so trying to sell software that costs a large fraction of the machine price doesn't make sense, while after paying $350,000 for a VAX, an extra $2000 of $5000 or whatever doesn't seem that much, especially if it saves the equivalent amount in programmer salary to develop the application locally. Now on the specific points: 1) Organizations that use VMS are used to spending more for the same functionality and performance. Universities are cheap. I can't believe that UNIX gives the same performance and functionality on a VAX as VMS does. This is not the place to go into details, but the resource management on VMS is far more advanced and efficient than on UNIX. 2) It is more difficult to make things work on VMS. Therefore there is less potential competition. What kind of remark is this? It is just as easy to make something work under VMS as it is in UNIX. In certain cases it is easier, for instance a data base application doesn't have to write an entire indexing record system from scratch. 3) VMS users tend to be end users while UNIX users tend to be capable of rolling their own applications. VMS users need more hand holding. I might agree that VMS users tend to be more end users than UNIX people, but I have to disagree with the last statement. I am perfectly capable of making my own applications, but I don't have the time to waste reinventing something that already exists and works (Another bonus of VMS systems, if it works under VMS, it works under any VMS), so if somebody has written a graphics and histogramming package, I am much happier to use it to accomplish the work I have to do, rather than writing my own. 4) UNIX software tools and the flexible UNIX user-system interface reduce the need for expensive software. The rigid user-system interfaces one finds in commercial operating systems like VMS creates an opportunity for the commercial software developer. The user system interface is irrelevant to the person who is developing application software, all he or she cares about is the input/output features of the language being used, and if the language is a standard one like C or Fortran, the IO is the same for VMS or UNIX. Is it possible that a lot of the UNIX software developed is duplicated effort that is repeated at many institutions? How many requests for C cross referencing programs have I seen on the net? In VMS, anyone who has a C compiler can make cross references. The descriptions of UNIX in the prefaces to the UNIX Programmers Manual, state that UNIX was developed as an environment for software development. However, VMS is an environment for software development and application running. Maybe people don't think of UNIX as an environment for running application programs, so they don't develop them. Eric G. Stern Dept. of Physics SUNY StonyBrook stern@bnl ...!philabs!sbcs!bnl!stern