hirai@swatsun.uucp (Eiji "A.G." Hirai) (02/29/88)
Hello Unix Wizards!
Our campus is almost on the verge of being turned into a VMS
filled campus due to the lack of knowledge of the person in charage of
computing services here. The next couple of months will determine
what the campus computer scene will be like during the next decade.
This person has in mind buying Vaxes with VMS, and DECnet with lots of
money...
Is VMS as horrible as I suspect or am I alone an thinking this?
Please help shed the light for us! Please tell us what you think would be
reasons why you wouldn't buy VMS! (or why you would). We need the help
of all you wizards out there. Any examples you can think of will help!
Thanks for your cooperation and knowledge. Is VMS that bad??
-a.g. hirai
outgunned sysadmin
--
Eiji "A.G." Hirai @ Swarthmore College, Swarthmore PA 19081 | Tel. 215-543-9855
UUCP: {rutgers, ihnp4, cbosgd}!bpa!swatsun!hirai | "All Cretans are liars."
Bitnet: vu-vlsi!swatsun!hirai@psuvax1.bitnet | -Epimenides
Internet: bpa!swatsun!hirai@rutgers.edu | of Cnossus, Cretebzs@bu-cs.BU.EDU (Barry Shein) (03/01/88)
>Hello Unix Wizards! > > Our campus is almost on the verge of being turned into a VMS >filled campus due to the lack of knowledge of the person in charage of >computing services here. The next couple of months will determine >what the campus computer scene will be like during the next decade. >This person has in mind buying Vaxes with VMS, and DECnet with lots of >money... The basic problem with VMS is that it locks you into a single hardware architecture and vendor. In this day and age that severely limits what you can purchase in computing power. Vaxes vary widely in price but not much in processing power. For example, a small uVax-II sells for around $30K and offers a little less than 1 MIP. An 8750 sells for perhaps $500K and offers a few MIPs. In the near future this range closes even further, the uVax-3 being around 1/2 the processing power of the top end with a price range of ten-fold. It's hard to buy worse price-performance. The Unix market ranges from PC based Unix systems which the average student can afford (and this area is expanding rapidly) to the Cray-2, a premiere super-computer, and just about everything in between. In the middle market (typical small-medium scale time-sharing) one can buy Unix systems from various vendors with upwards of ten times the price performance of VMS. Unix systems are relatively bundled, beyond mere hardware considerations most Unix systems right out of the box are completely useable. It can be supplemented in many significant ways with free or nearly free (eg. ~$100 for an entire campus) software. VMS is heavily unbundled, from day one if you want so much as a compiler you begin layering heavy costs. And you'll pay a separate price for acquiring and maintaining software on every CPU running VMS on campus. This will quickly lock you out of the workstation market, having to add $100K in basic software costs to 40 VMS workstations can put a real damper on a typical University's plans, no matter how good the intentions. Unix is the premiere system for compute intensive areas, such as the sciences using Fortran. The reason is the vast range of power a program written to run under Unix presents. As I said, a program developed on a small, affordable PC or workstation can be copied and re-run on huge compute engines. Although a lot of the sciences in the past used VMS they now generally realize that this was an error and the communities are rapidly switching to Unix, any argument that science is done on VMS is a false argument of the past. You should poll major science depts and research labs. If nothing else, the fact that the Cray and other super-computers run Unix has pushed the equation in this favor, a person using VMS is essentially locked out of the entire NSF super-computer initiative. Decnet would tend to reaffirm this retardation (TCP can be had on VMS but it's sort of like teaching a pig to dance, speak to VMS sites and they'll tell you what a general pain in the ass it is to deal with third party vendors, network software breaking on each O/S release etc etc.) The typical claim by the campus administrator is to point at all the myriad applications and big-name software that runs on VMS and doesn't run on Unix. In the first place, most of this now does run on Unix so that tends to be an anachronistic view. Another point is that such admins usually have DP-envy. No one on the campus has any need for any of the big-name applications the person is bragging about, you're running an academic environment, not a bank! Get a list of these applications and you'll see how ludicrous this consideration is. Unix tends to vastly dominate the academic community in software availability. These admins will sneer at things like X-windows, lisp (which doesn't cost $10K/node), AI systems etc in preference to their big-name commercial databases and spread-sheets as if what students and professors do is not to be taken seriously, then why are they on a campus? It's no accident that both Athena and Andrew have chosen Unix for their massive campus computing projects. Unix makes available the forefront of hardware technology, parallel processing from companies like Encore, Sequent, BBN (Butterfly), RISC and the so-called "super-workstations" like Sun/4, MIPS, HP etc. which can deliver nearly 1MIP/$1K of price. The parallel processor provide time-sharing systems extending into the hundreds of MIPs, again for about $1K/MIP. Anything new and innovative runs Unix, not VMS, it would be foolish to lock an entire academic community out of all this. I can understand why a bank is not particularly concerned, but why a (supposedly) active research community? Why lock yourself out of all this. The VMS salesthings will claim that they're going to do all this *in the future*, they've been saying that for years and years, and when they do come out with something it tends to be too little too late, in name only, like a dual processor 8800 which barely exploits what tiny parallelism it has. VMS itself is not an interesting operating system to learn or study. It is basically a re-work of RSX, an ancient real-time operating system from the PDP11 (Unix also ran on the PDP11 years ago, but it has grown in modern ways, as opposed to VMS's habit of just accreting whatever features were needed to meet the next big govt contract.) The claim that Unix is somehow less secure than VMS is a red herring. Unix offers sufficient security for campus systems, you're not the NSA (again the tactic of arguing that VMS is better for things you don't need.) More importantly, many Unix systems are available with full sources for a modest price, typically $1000/campus (it's simply a matter of your vendor choices, more than you can say for VMS where there is no choice.) Without the sources you are, at best, at the mercy of the vendor for security. A huge security hole which is bringing you to your knees (which happens regularly on VMS, and the news travels the networks like wildfire) leaves you helpless and at the vendor's whims as to whether or not they feel like closing the hole this week, or next month, or put it off for next release. In fact their concern with only commercial DP makes them *less* interested in your security problems. Banks don't have malicious students exploiting security holes and don't tend to notice such things or complain about them. With Unix and the sources you can at least plug up the hole by a code change and then call the vendor and wait for the real fix, at least you'll be up and running until then. Don't believe that VMS sources are available, it's a lie, demand to see prices for all items needed such as Decnet sources. Demand to be told what resources it would take to even manage such sources. Last I checked it required the dedication of a few hundred thousand dollars in hardware (basically, an entire larger Vax with large disks) to manage sources. Obviously the sources will also be of enormous benefit in answering user questions, such as tracking down example code using particular system calls. You can sort of do this with VMS's microfiche, if you consider searching through microfiche for a particular system call usage a good way to spend your time. You can't grep microfiche. Even then you'll usually find that the way the system application accomplishes what the user seems to want to do is by exploiting some privilege you won't want to give to a user (I'm not sure I want to go into the whole mess of the zillions of VMS "privilege" bits which you'll never fully understand the implications of and will almost surely end up giving away the store because some reasonable thing can only be accomplished by giving a user some dangerous privilege bit, Unix's single privilege scheme [root or not root] is much more secure, you just don't give out root privs and you know exactly what can and cannot be done by the two sets of users on your system, who wants to calculate the permutations of 30+ priv bits and what they might imply singly and in combination?.) The programming and system interfaces in VMS are arcane and just a hodgepodge of features, there's no particular underlying design philosophy, just whatever marketing wanted this week. Although VMS has some interesting software features it's nearly impossible for anyone but a very experienced programmer to take advantage of these. This is not really a damnation of VMS, VMS is a platform for delivering turnkey applications software, like databases in commercial environments for people who wouldn't think of programming in general, just data entry and report generation. I'm *sure* this is representative of your needs (hah!) In an academic community one merely has to go into a campus bookstore to see another argument. Look at all the Unix books! Where are the VMS books? There are none. A complete set of Unix manuals costs less than $100, a more than sufficient set costs perhaps $50. A complete set of VMS docs costs several hundred dollars, no student or even faculty member (except the few richest) can afford to own a documentation set for VMS. There's some on-line help in VMS but it's designed to sell manuals or supplement them, the details are always missing (purposely.) Most Unix systems come with on-line, complete manual sets with the exact same text used to produce the printed manuals. Thus, what's the cost to a student for Unix manuals? For $0 (zero) they can get everything, if they like manuals in their laps they can buy those for the cost of a couple of textbooks. To supplement that they can buy any of dozens of titles on Unix ranging from the structure of the operating system, systems programming, compiler construction, applications programming, AI, many programming languages, shell programming, text processing etc etc. For VMS you'll be lucky to find two titles (I can only think of one, the Internals book, and that's hardly a text, oh yeah, there's an assembler textbook, both of those are about five years old and don't even refer to the current VMS system so you won't be able to use their code etc.) So, running courses on VMS will mean foresaking textbooks. Very clever! Good plan for running an academic environment! It's no accident, the DEC/VMS crowd has no interest in academia, your sysadmin has DP-envy. Decnet nearly completely locks you out of wide-area networking, such as the arpanet. One need only look at the arpanet's University rolls to see who you are abandoning, merely the foremost schools and research labs in the country. About 95% of them use Unix systems to hook up to the arpanet. Decnet is completely useless in this regard. There are a couple of strange, semi-wide area networks based on DECNET (few people could name them.) Perhaps one or two of your faculty would like to be on them. You should buy them a microvax and get on with the rest of the campus' needs, don't let the tail wag the dog. And you can forget uucp and usenet entirely, which means no e-mail to vendors etc. In summary, buying into VMS for a campus is buying into the past in a pathetic, nearly necrophilic way for an academic community. It locks them out of the mainstream in Computer Science, Engineering, the Sciences and many of the humanities (all the multi-media projects of any interest are being done on either Unix or or Macintosh/PC systems.) It has very little to offer an academic community for either research or coursework. It is flying in the face of nearly all trends in computing today and doing so at such a high dollar price that it borders on irresponsible. This is not to say that there is no need for even one VMS system on your campus, there probably is. But using it as a campus standard is irresponsible and completely without merit or rational justification and will cripple academic computing for years to come. What other campuses do this? This is not a religious flame, I have presented myriad factual basis for my arguments. VMS people like to claim religious flame and "chocolate vs vanilla!" arguments. This is because they cannot deal with the real issues so making it a political war can only act to their advantage. Avoid the issues, get the opponents fired, scare a campus administrator with false promises of donations etc. Unfortunately you may be up against an insidious cancer you only barely understand which will manipulate your organization in ways you will regret. -Barry Shein, Boston University
trt@rti.UUCP (Thomas Truscott) (03/01/88)
In article <1636@tulum.UUCP>, hirai@swatsun.uucp (Eiji "A.G." Hirai) writes: > Is VMS as horrible as I suspect or am I alone an thinking this? VMS is a fine OS. Any campus should have a few VMS systems. But your campus should primarily run UN*X. This partly because UNIX is wonderful and partly because UNIX has become so widespread that it should be chosen even when clearly deficient. (E.g. people still choose FORTRAN.) 1. As a University, it is absolutely mandatory to make UNIX the major academic operating system. * undergraduates should use it because it is what they will use when they graduate. * graduate computer science/engineering students can study, and even modify the UNIX OS. Thousands of students have learned how to write operating systems by studying UNIX. Not true of VMS! Consider MIT (Project Athena), CMU (Mach OS, and Andrew), University of Califorina at Berkeley (3.0 BSD and so on). Consider the following major academic software projects: Sprite, Locus, TimeWarp, (forget this, consider *almost any* recent major academic software project!). UNIX had a major role in every one. * Look at the CS faculty recruiting ads in the back of the Communications of the ACM, and count how often UNIX is mentioned. Can you even *find* a mention of VMS? * What about the non-CS students and faculty? If they want innovative uses of computing they will find it on UNIX. Mostly they will want word processing, and that is on UNIX too. (But a SUN or Mac or PC clone is cheaper for that than a VAX. Whatever you pick can run UNIX. VMS only runs on a VAX.) 2. As a strategic computing decision, you must pick UNIX, because it is becoming a world-wide standard operating system. It can run on nearly every computer from the smallest home systems to the Cray 2. Virtually every newly designed computer has UNIX as the standard (if not the only) operating system. Older operating systems will persist, of course, but their vendors now provide UNIX alternatives. In particular there are vendor-supplied UNIX alternatives to IBM MVS, DEC VMS, Apollo Domain, Prime OS, DG AOS, Gould MPX, and Apple MacOS. Any "tactical" gain from chosing VAX VMS initially will quickly lose to (a) improvements in VAX UNIX (e.g. DEC's Ultrix) and (b) improvements in the UNIX computing world in general. 3. DECnet is a limited network, limited mainly to Vaxen. TCP/IP is currently the obvious choice for networked laser-printers, terminal concentrators, and so on. As other choices become obvious UNIX will have them, and will have them before any other operating system does. (UNIX already has several networking alternatives, such as XNS.) Ultrix has DECnet, but it should be used only to communicate with your VMS systems. ========== Some non-technical notes: Your computing services manager may already have committed to VMS, so this may be a pointless battle. Unless you have something to lose, though, you should have a long chat with "him" anyway as he should know what he will be up against later. Survey other colleges similar to yours (maybe just scan faculty recruiting ads as mentioned above) and see what they are doing about computing. Your manager probably has done so, make up your own list. Ever since VAX was built, the UNIX vs. VMS question has been asked. I have about 200 kilobytes of answers (mostly in favor of UNIX!) for everything from real time to office automation. As time goes by, the answers change. And it is mostly due to the tidal wave of UNIX engulfing the computing world, making the smaller technical details completely irrelevant. For example, past claims such as "FOO runs only on VMS" took time to answer, now it is simply "DEC shipped/will ship FOO on Ultrix last/next summer." From what I heard at the Ultrix BOF at the last Usenix conference, DEC is now committed to equal development/support of new products on both VMS and UNIX, which may benefit both systems by encouraging competition between the two porting teams. Tom Truscott
cetron@utah-cs.UUCP (Edward J Cetron) (03/01/88)
In article <1636@tulum.UUCP> hirai@swatsun.uucp (Eiji "A.G." Hirai) writes: > > Is VMS as horrible as I suspect or am I alone an thinking this? >Please help shed the light for us! Please tell us what you think would be Anyone who can answer this article with a firm response that ??? is better then *** is not worth listening to. Both operating systems have there place, and until you can indicate what purpose you will use them for, all you will receive is useless flamage..... Here at Utah, we run both, we do heavy number crunching with load balancing on our vaxcluster using VMS since we feel it is better for that type of situation, and for the robotic control efforts we use Unix boxes. And yes they both talk to each other just fine, and people work on both just fine and I here just as many complaints of the 'why doesn't unix keep multiple versions' type as of the 'why doesn't vms have good filters'. First define what you want to accomplish over the next several years - is it teaching? cs research? production activities?..... THEN repost your question. -ed Manager, Computer Services Center for Engineering Design Univ of Utah cetron@cs.utah.edu
matt@oddjob.UChicago.EDU (Mr. nEtural) (03/01/88)
Let me add a few words to Barry's many. We (the University of Chicago) have joined one of the wide-area DECNET networks that Barry alludes to. Since we joined, not one month has passed without an urgent bulletin from the agency which runs the network, alerting all nodes to a break-in. One or another group of malicious crackers finds a hole in the DECNET software which allows them to penetrate nearly every VMS node on the network. All we get are instructions on how to detect and fix the typical damage done by each group. When was the last time you heard of a similar break-in against unix systems? The only one I can remember was a couple years ago, and source and object-only fixes to the buggy system program were circulated almost instantly. Matt Crawford
wesommer@athena.mit.edu (William E. Sommerfeld) (03/01/88)
In article <14433@oddjob.UChicago.EDU> matt@oddjob.UChicago.EDU (Mr. nEtural) writes: >Let me add a few words to Barry's many. > >When was the last time you heard of a similar break-in against unix >systems? The only one I can remember was a couple years ago, and >source and object-only fixes to the buggy system program were >circulated almost instantly. I think that there was another rash of breakins somewhat more recently (~1 year ago?) which got a lot of press on RISKS among other places. None of the breakins were due to software bugs per se, but rather to sloppy protection configurations and overly trusting .rhosts files. These types of security holes are particularly tricky to deal with, and sometimes quite easy to exploit; a friend of mine has broken into Multics systems (though not ones being run by the DoD) using these techniques with the Multics equivalent of UUCP. He wound up with a ring-zero gate - the equivalent of his own private system call - and had some fun `playing god' before he made a bug report. He had reported the same problem earlier, but it was ignored as `not a security hole'. - Bill
rbj@icst-cmr.arpa (Root Boy Jim) (03/01/88)
Is VMS as horrible as I suspect or am I alone an thinking this? You are not alone. Please help shed the light for us! Please tell us what you think would be reasons why you wouldn't buy VMS! (or why you would). We need the help of all you wizards out there. Any examples you can think of will help! Tell him to spend some time recruiting CS students. Tell him that if they run VMS, no one will come to your school. Tell him about the lack of *real* vendor support, regardless of what they promise. There will be nothing for the hordes of wizards to do without source code. And finally, mention the lack of real, modern, compatible networking. Of course, after you go thru all this, then you'll have to convince him to run BSD over System V. At the very least, have him stage a test, in which some VMS and some UNIX systems are supported. See which one is preferred. At least you'll be able to salvage the hardware. Thanks for your cooperation and knowledge. Is VMS that bad?? Not if you enjoy banging your head against the wall. National Bureau of Standards Flamer's Hotline: (301) 975-5688 FOOLED you! Absorb EGO SHATTERING impulse rays, polyester poltroon!!
lm@arizona.edu (Larry McVoy) (03/01/88)
In article <20268@bu-cs.BU.EDU> bzs@bu-cs.BU.EDU (Barry Shein) writes: >Unix is the premiere system for compute intensive areas, such as the >sciences using Fortran. The reason is the vast range of power a >program written to run under Unix presents. As I said, a program >developed on a small, affordable PC or workstation can be copied and >re-run on huge compute engines. Although a lot of the sciences in the >past used VMS they now generally realize that this was an error and I agree with the rest of the article but this part is not completely true. VMS fortran is the de facto industry standard. Until I can have all the VMS extensions (and there are a lot of very useful ones) this argument does not hold water. Sorry, Barry, but we can't misrepresent the facts. And maybe Ultrix supports them (I don't know) but that's not enough - your argument said from the PC to the super computer (super computer companies take the VMS extensions _very_ seriously). I really feel sort of gross sticking up for VMS but this is one place that it shines, and fair is fair. -- Larry McVoy lm@arizona.edu or ...!{uwvax,sun}!arizona.edu!lm
jsloan@wright.EDU (John Sloan) (03/01/88)
in article <1636@tulum.UUCP>, hirai@swatsun.uucp (Eiji "A.G." Hirai) says: > Please help shed the light for us! Please tell us what you think would be > reasons why you wouldn't buy VMS! (or why you would). We need the help > of all you wizards out there. Any examples you can think of will help! I am not a wizard. I manage a laboratory with (as of last week) twenty Unix systems ranging in size from a SUN-3/280S (our principal timesharing system), a cluster (in the generic sense) of SUN-3 workstations with a 3/180S server, a VAX 785, a VAX 750, some NCR Tower 32/600s, and some smaller machines. Most of the engines are ethernetted together, and the VAXen and SUNs are all integrated using NFS and YP to provide a computing environment where CPUs are considered merely peripherals: if you need a bigger one, put it online on the net and use it, and don't worry too much what it is or where it came from. Our of four computer centers on campus (i.e. organizations which have some degree of centralized computing in terms of geographical location and management), we are the only Unix shop, the rest being VMS with one IBM mainframe for administrative work. I am fighting the same fight you are, arguing with the computer center Directors and a Vice President. I object to the term wizard, and if you're smart, you'll drop it too. I am not a wizard, and none of the 2.7 FTE people that work for me supporting our environment are wizards either. Unix _must_ shake the reputation of needing a wizard to maintain it if it is going to be accepted in organizations where skilled labor is expensive and hard to find. I am incredible fortunate, and I know that. I have highly skilled, motivated, educated (most with a M.S. in C.S.), and _experienced_ people working for me, but your typical campus computer center is usually not that fortunate. Our center tried to hire one of my people away (I think I would have gladly let him go, if only to improve conditions at center), and he was seriously considering it until they discovered that he would have to take a pay cut. So much for competitiveness in salary, even within the University, and I can't pay what the people just across the street will pay for the same person. Don't say wizard. Don't say guru. "Systems manager" might be okay. But don't give anyone the idea that you need a wizard to maintain a Unix system because [A] it just isn't true anymore, if it ever was, and [B] it will discourage any migration to Unix. Why Unix? I sit on a committee that reports to our VP for Computing (a CIO in corporate parlance) that is supposed to advise our Computer Center Directors on purchases, policy, procedure, etc. DEC has delivered a proposal for a 6MIPS VAX for $1.2M. Six months ago I purchased, received, and deployed our Sun-3/280S, a 4MIPS engine for under $100K. Question: which is the better deal? Answer: The $1.2M VAX. Because it runs VMS. Never mind that for CPU intensive applications (which is predominantly what we're talking about here) the VAX is _eight_ times more expensive (with comparable amounts of disk space and memory) than the Sun. The Sun doesn't run VMS. The time has come for us to realize the _true_ cost of proprietary technologies. When you run VMS you have _one_ name in your rolodex card file, and it says "Digital". It is no longer a question of getting the most for your money; it is a matter of finding out from your sales rep how many zeros to write on the check. There is another issue than capital investment: intellectual investment. Unix has a reputation as being user hostile or having a steep learning curve, and yet once that learning curve has been achieved, your intellectual investment is protected across an incredible number of machines and models for many many vendors. Sure, there are differences between the system calls or management from system to system, but at least I can sit down and immediately begin editing, manipulating files, using tools, helping me while I learn those differences. And for many users, there _is_ no difference. When we moved our faculty off our 750 onto the 3/280S, the only difference (besides vastly improved response time) that they noticed was that the role or "R" and "r" in the mail command was reversed... which lasted until we figured out how to change it. These two machines are from different vendors, and have different architectures, but they had one thing in common: both had common roots in Unix. There are financial considerations here too, in terms of productivity and training costs. I spent five years as a systems programmer in an IBM mainframe environment, and when I left I was the senior technical resource in my shop. I spend two years in a PDP-11 environment, two years in a VAX/VMS environment, and the past two years in our current Unix environment. I can say without reservation that Unix is the most useful, most productive, and most (dare I say it?) _friendly_ environment that I, as a professional programmer and manager, have ever had the pleasure of using. Subjective opinion? Hmmmmm.... perhaps. But I'm not so sure. In the end, you will have to find your own justification, your own strategy. On my end, I am confident that the University will continue to fritter away the taxpayers money on proprietary technologies, while I work hard on providing the best, most cost effective computing environment for the money. I apologize for the length of this. I know, few hard facts, mostly just soapboxing. Perhaps it will prompt some discussion. I wish you luck. -- John -- John Sloan Wright State University Research Center CSNET: jsloan@SPOTS.Wright.Edu 3171 Research Blvd., Kettering, OH 45420 UUCP: ...!cbosgd!wright!jsloan (513) 259-1384 (513) 873-2491 Logical Disclaimer: belong(opinions,jsloan). belong(opinions,_):-!,fail.
roy@phri.UUCP (Roy Smith) (03/02/88)
In article <1636@tulum.UUCP> hirai@swatsun.uucp (Eiji "A.G." Hirai) writes: > Is VMS as horrible as I suspect or am I alone an thinking this? Personally, I think VMS sucks and Unix is wonderful. Judging from the other recent responses, I'd say that is the majority opinion on the net. But (and it's a big But), remember that you are dealing with a very strong self-selection factor. Ask a bunch of unix wizards if Unix is better than VMS and the answer will be pretty predictable. I wonder if you would get the same answer if you stood up at a DECUS meeting and asked the same question? The strongest single factor that Unix has going for it (in my opinion) is that it runs on zillions of different kinds of hardware. We used to run on pdp-11's and vaxes. Now we run mostly on Suns. Tommorow, who knows? Maybe we'll buy a Sequent or an Alliant. Maybe PC's. The common theme is that they are all Unix, making porting program and user skills orders of magnitude easier than moving from one OS to another each time we change vendors. Up until recently, the biggest reason I could think of to have VMS is because lots of other people do; we get a lot of big VMS FORTRAN programs which will only run on VMS because they depend on VMS extensions. We were seriously thinking of buying a small Vax to run VMS on just for those applications. What we have done instead is order Sun's VMS compatable FORTRAN compiler so we can run that VMS FORTRAN on our Unix boxes and have the best of both worlds. Before committing to VMS, find out if it supports NFS (Sun's Network File System), TCP/IP, and NeWS and/or X. If it supports all those (and supports them well, without resorting to third-party software add-ons) then you should not have too much trouble integrating into the rest of the world. VMS almost certainly doesn't support uucp, but this can probably be considered as much of a blessing as a curse. -- Roy Smith, {allegra,cmcl2,philabs}!phri!roy System Administrator, Public Health Research Institute 455 First Avenue, New York, NY 10016
riddle@woton.UUCP (Prentiss Riddle ) (03/02/88)
I asked a similar question a few months ago and received a number of
flame-free replies. If it would be useful for me to re-post a summary,
let me know.
--- Prentiss Riddle ("Aprendiz de todo, maestro de nada.")
--- Opinions expressed are not necessarily those of my employer.
--- riddle@woton.UUCP {ihnp4,harvard}!ut-sally!im4u!woton!riddledavidsen@steinmetz.steinmetz.UUCP (William E. Davidsen Jr) (03/02/88)
In article <4080@megaron.arizona.edu> lm@megaron.arizona.edu (Larry McVoy) writes: | [...] | I agree with the rest of the article but this part is not completely | true. VMS fortran is the de facto industry standard. Until I can have | all the VMS extensions (and there are a lot of very useful ones) this | argument does not hold water. Sorry, Barry, but we can't misrepresent I have played with vcc (VMS C under Ultrix) a little and it seems to be the smae compiler that we know a love. I have heard rumors about a similar effort on FORTRAN, but I have no solid information. Does anyone have at least solid rumors? -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs | seismo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
paradis@encore.UUCP (Jim Paradis) (03/02/88)
In article <4080@megaron.arizona.edu> lm@megaron.arizona.edu (Larry McVoy) writes: >I agree with the rest of the article but this part is not completely >true. VMS fortran is the de facto industry standard. > >I really feel sort of gross sticking up for VMS but this is one place >that it shines, and fair is fair. Well, I know of at least one company that produces a VMS-Fortran package for UNIX. In fact, it even comes with a DCL-like command interpreter and (I think) an EDT-like editor. The name slips my mind right now, but I'll see if I can dig up a reference... +----------------+ Jim Paradis linus--+ +--+-------------+ | Encore Computer Corp. necntc--| | | E N C O R E | | 257 Cedar Hill St. ihnp4--+-encore!paradis | +-------------+--+ Marlboro MA 01752 decvax--| +----------------+ (617) 460-0500 talcott--+ Well, what's the pleasure in THAT??!!
ok@quintus.UUCP (Richard A. O'Keefe) (03/02/88)
In article <4080@megaron.arizona.edu>, lm@arizona.edu (Larry McVoy) writes: > I agree with the rest of the article but this part is not completely > true. VMS fortran is the de facto industry standard. Until I can have > all the VMS extensions (and there are a lot of very useful ones) this > argument does not hold water. Sorry, Barry, but we can't misrepresent > the facts. And maybe Ultrix supports them (I don't know) but that's > not enough - your argument said from the PC to the super computer > (super computer companies take the VMS extensions _very_ seriously). > If this is so, it would be interesting to know why Fortran 8X does not resemble VMS Fortran. For example, both let you define record types, but the syntax is very different. IBM's FORTVS doesn't seem to have copied much from VMS Fortran either, I've carefully checked a recent IBM Fortran manual and couldn't find any of the features that make VMS Fortran so sexy. Apollo's Fortran hasn't any of the VMS extensions that I know of. "de facto industry standard"? Maybe on Vaxen. The extensions in VMS Fortran are precisely the reason why the original point is valid: there are so many extensions in VMS Fortran that if you don't watch out you will write wonderful programs that are ever so much clearer than you could have written under UNIX, but you never be able to run them on non-DEC equipment. (DEC's VMS C compiler is available under Ultrix, does anyone know whether the VMS Fortran compiler is available under Ultrix as well?) Perhaps a survey of the features of VMS Fortran, and a list of which super-computer companies have copied which extensions, would be a good topic for comp.lang.fortran. Unlike some other proprietary operating systems, VMS is not a major nuisance for university computing. There is a lot that is good about it. But it *IS* a proprietary operating system, and the compilers available for it *ARE* proprietary compilers, and RDB *IS* a proprietary data base. Using UNIX gives you more freedom in selecting additional/ replacement machines. Imagine a central VAX, with a dozen or two SUNs, a couple of Pyramids, and maybe a Sequent or two. Only one of them can run VMS, but they can all run UNIX, and it isn't hard to write programs in C or Fortran which only need recompilation to move from one to another.
terrell@musky2.MUSKINGUM.EDU (Roger Terrell) (03/02/88)
In article <1636@tulum.UUCP> hirai@swatsun.uucp (Eiji "A.G." Hirai) writes: > Is VMS as horrible as I suspect or am I alone an thinking this? >Please help shed the light for us! Please tell us what you think would be >reasons why you wouldn't buy VMS! (or why you would). We have both UNIX and VMS here at Muskingum, and my experience is that both have distinct advantages: VMS ADVANTAGES: - VMS is *friendly*; more so than any flavor of UNIX - the Run-time library that comes with VMS is extremely powerful and is getting better still in the upcoming version of VMS (5.0). - VMS is much more secure, although this does not mean much in an academic environment unless there is a lot of research and/or the administrative people are paranoid. - The DEC compilers are VERY nice. - VMS documentation blows UNIX documentation out of the water (someone pointed out that you don't find VMS manuals in a bookstore; that is correct, but it is not bad. It is because VMS is so much larger and is designed for a larger type of machine). - The editors on VMS (TPU especially) are quite powerful. UNIX ADVANTAGES: - Many text-oriented tools are available. - The UNIX shell "languages" are much better than DCL. - UNIX has better facilities to deal with programs which use more than one process. - UNIX has UUCP (and, therefore, Usenet) ** major plus here ** I certainly would not say that an all-VMS campus is a good thing, if for no other reason than that students should be exposed to several different operating systems. The thing that I prize UNIX most for is UUCP/Usenet. The thing that I prize VMS most for is its powerful software development tools. --Roger P.S.: Let us know how it turns out... -- Roger Terrell Muskingum College ...cbosgd!musky2!terrell (UUCP) New Concord, OH 43762
hartzell@beagle (George Hartzell) (03/03/88)
In article <717@cresswell.quintus.UUCP>, ok@quintus (Richard A. O'Keefe) writes: >VMS Fortran so sexy. Apollo's Fortran hasn't any of the VMS extensions >that I know of. "de facto industry standard"? Maybe on Vaxen. Yes, there is a vms-fortran compatible compiler available under ultrix that works fairly well. Sun is also selling a VMS extended fortran, but when I tried it 3-4 months back it wasn't working very well. -- George Hartzell (303) 492-4535 MCD Biology, University of Colorado-Boulder, Boulder, CO 80309 hartzell@Boulder.Colorado.EDU ..!{hao,nbires}!boulder!hartzell (bitnet hosts try: hartzell%boulder.colorado.edu@jvnca.csc.org)
klb@philabs.Philips.Com (Ken Bourque) (03/03/88)
*>In summary, buying into VMS for a campus is buying into the past in a
*>pathetic, nearly necrophilic way for an academic community.
*>
*>Using it as
*>a campus standard is irresponsible and completely without merit or
*>rational justification and will cripple academic computing for years
*>to come.
*>
*>Unfortunately you may be up against an insidious cancer
*>
*>This is not a religious flame
--
Ken Bourque klb@philabs.philips.com ...!{uunet,ihnp4,decvax}!philabs!klbdavid@elroy.Jpl.Nasa.Gov (David Robinson) (03/03/88)
In article <68@musky2.MUSKINGUM.EDU>, terrell@musky2.MUSKINGUM.EDU (Roger Terrell) writes: > VMS ADVANTAGES: ... > - VMS documentation blows UNIX documentation out of the water Huh?! VMS is VERY poorly documented if you want to do anything non-trivial. They tend to only cover the obvious cases, and leave you to guess at the complex cases. All sorts of things are hidden or undocumented. -- David Robinson elroy!david@csvax.caltech.edu ARPA david@elroy.jpl.nasa.gov ARPA {cit-vax,ames}!elroy!david UUCP Disclaimer: No one listens to me anyway!
douglas@dcc1.UUCP (Douglas B. Jones) (03/03/88)
Greetings: In article <1636@tulum.UUCP> hirai@swatsun.uucp (Eiji "A.G." Hirai) writes: >Hello Unix Wizards! > Our campus is almost on the verge of being turned into a VMS >filled campus due to the lack of knowledge of the person in charage of >computing services here. The next couple of months will determine >what the campus computer scene will be like during the next decade. >This person has in mind buying Vaxes with VMS, and DECnet with lots of >money... > Is VMS as horrible as I suspect or am I alone an thinking this? >Please help shed the light for us! Please tell us what you think would be >reasons why you wouldn't buy VMS! (or why you would). We need the help >of all you wizards out there. Any examples you can think of will help! > Thanks for your cooperation and knowledge. Is VMS that bad?? > -a.g. hirai > outgunned sysadmin >Eiji "A.G." Hirai @ Swarthmore College, Swarthmore PA 19081 | Tel. 215-543-9855 >UUCP: {rutgers, ihnp4, cbosgd}!bpa!swatsun!hirai | "All Cretans are liars." >Bitnet: vu-vlsi!swatsun!hirai@psuvax1.bitnet | -Epimenides >Internet: bpa!swatsun!hirai@rutgers.edu | of Cnossus, Crete Here are some tad-bits: 1) Here is an interesting quote from "Digital News" on February 22, 1988. This come from the front page article "Customers Shown VMS 5; Symmetrical VAX Awaited" by "Gerard Bidal and DIGIT News Staff". Starting with paragraph 3 (note that 5.0 below refers to VMS 5.0): " While many observers have been expecting version 5.0 and the new VAX to be released at the same time, there is a hint that Digital may release the new machine under Ultrix, its Unix operating system, before the new VMS is ready, which will probably be in June, according to one well-informed Digital customer. Sources say Digital sales representatives are being briefed not to be surprised if, in the future, new systems are released first under Ultrix and later under VMS." There is also more in the above article that makes one wonder about DEC and the UNIX (ULTRIX) vs. VMS wars. 2) USENIX Conference Proceedings,Winter 1988, in Dallas, Texas, February 9-12. Afternoon Session A: Kernal Papers. There are several topics here, but one caught might eye real fast: "An Experimental Symmetrix Multiprocesser Ultrix Kernel, page 283, bye Graham Hamilton & Daniel S Conde (Digital Equipment Corporation)" At the beginning of proceedings book it says: "For additional copies of these proceeding, write: USENIX ASSOCITATION P.O. Box 2299 Berkeley, CA 94710 USA Price $20.00 plus $15.00 for overseas airmail. 3) VAX Clusters I went to a Digital school in Dallas the week after the above USENIX conference. At the school, one of the other "students" told us that thier site was going to be the (or a ?; most likely the) test site for ULTRIX clustering. That is suppose to happen (if my memory is correct) some time this March. I believe it was between a VAX 11/78? and 86?0. 4) On the fith page of the Digital brochure "ULTRIX Worksystem Software: Faster, Easier, and More Accessible Than Ever" There is an X-window picture (right hand page). There are a "bunch" of yellow boxes at the top of the picture. I think these are directories in reference to the users mail that he/she has received. Here are some of those boxes/ mail_directories that caught my eye: 32-2.0 (ULTRIX) 32-2.1 (ULTRIX) 32-2.2 (ULTRIX) 32-3.0 (ULTRIX) 32.thd (32.tbd) (ULTRIX) 32w Athena (this is talked about in good detail in the Conference Proceedings from the Dallas USENIX Conference) LN03 (LASER printer) LN01S (LASER printer) LN03 (LASER printer) LN03R (LASER printer) LN04 (Hum....) LPS40 (LASER printer/print server) and there are other boxes of interest also. The main ones above that caught my eye were 32-3.0 (I think this is the cluster ULTRIX as othere(s) have mentioned in previous net articles) and LN04, which I have not heard of. The number on the back of the brochure is "EA-30516-43". Hope the above sound interesting to some of you..... Douglas ------------------------------------------------------------------------- -- Douglas B. Jones {cbosgd,hplabs,ihnp4,seismo,ulyses}!gatech!dcc1!douglas DeKalb College douglas@dcc1 555 N. Indian Creek Drive Clarkston, Ga. 30021
dhesi@bsu-cs.UUCP (Rahul Dhesi) (03/03/88)
In article <284@wright.EDU> jsloan@wright.EDU (John Sloan) writes: >DEC has delivered a >proposal for a 6MIPS VAX for $1.2M. Six months ago I purchased, >received, and deployed our Sun-3/280S, a 4MIPS engine for under >$100K. I forwarded this and two previous articles on this theme from comp.unix.wizards to comp.os.vms because I thought they deserved wider circulation. The UNIX versus VMS battle was lost and won some years ago, around 1984, I think. It's all moot now. But if you still discuss it, it would be a good idea to let both comp.unix.wizards and comp.os.vms readers follow it. It will also add balance, since the real VMS defenders are all in comp.os.vms. -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesi
alex@umbc3.UMD.EDU (Alex S. Crain) (03/03/88)
In article <5586@elroy.Jpl.Nasa.Gov> david@elroy.Jpl.Nasa.Gov (David Robinson) writes: >In article <68@musky2.MUSKINGUM.EDU>, terrell@musky2.MUSKINGUM.EDU (Roger Terrell) writes: >> VMS ADVANTAGES: >... >> - VMS documentation blows UNIX documentation out of the water > >Huh?! VMS is VERY poorly documented if you want to do anything non-trivial. >They tend to only cover the obvious cases, and leave you to guess at the >complex cases. All sorts of things are hidden or undocumented. I'm sure that VMS is completely documented, I just haven't found the right manual yet. I've been working my way through the manuals in the document library and I'm half way through the second cabnet, (3 shelves to go), So I should find what I'm looking for by mid May. I hope I can remember what it was by the time I find it. I had this idea for a new horror film, "VMS Manuals from Hell" or maybe "The Paper Chase : IBM vs. DEC". Its based on Hitchcock's "The Birds", except that It's centered around a programmer who is attacked by a swarm of binder pages with an index number and the single line "This page intentionally left blank." -- :alex. nerwin!alex@umbc3.umd.edu alex@umbc3.umd.edu
dhesi@bsu-cs.UUCP (Rahul Dhesi) (03/03/88)
In article <68@musky2.MUSKINGUM.EDU> terrell@musky2.UUCP (Roger Terrell) writes: > >VMS ADVANTAGES: > - VMS is much more secure, although this does not mean much in an >academic environment unless there is a lot of research and/or the >administrative people are paranoid. There is a widely-held belief that the less an environment allows people to do, the more secure it must be. By this strange definition, the ultimate in security is achieved by not letting anybody log in at all. VMS wins very easily, then, since each user's authorization record has a DISUSER field. In one fell swoop you can disuser all your users, since the relevant command will accept wildcards. However, I prefer to believe that the more you can let your users do without harming the system, the better your system's security is. The ideal secure system would put no restrictions at all on what users could do, yet it would not be maliciously crashable or allow privacy to be breached. (It would also unfortunately succomb to Russell's or a similar paradox and presumably vanish in a puff of logic.) UNIX does come pretty close, though. -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesi
mcpherso@msudoc.ee.mich-state.edu (Mike McPherson) (03/03/88)
Can we *please* stop the UNIX vs. VMS argument. We have both, we like both. <flame on> YOU PEOPLE ARE WASTING MY TIME!!! <flame off>
garry@batcomputer.tn.cornell.edu (Garry Wiegand) (03/04/88)
In a recent article mcpherso@msudoc.UUCP wrote: ><flame on> > > YOU PEOPLE ARE WASTING MY TIME!!! > ><flame off> Go away, please. We have both, we like both too. But, as professionals, it's always interesting to discuss what makes a good computer. The VMS vs Unix holy war is unusually fun and enlightening because people have such strong opinions and ideas about it. Most of what goes by on these newsgroups can be classified as "data" - people reporting random bits of technical info to each other. Topics that inspire people to *think*, on the other hand, are rare. I've gained a *lot* more enlightenment from "Unix vs VMS" than from all the usual grungy junk around here. Harrumph. garry wiegand (garry@oak.cadif.cornell.edu - ARPA) (garry@crnlthry - BITNET) PS - I'd like to publicly thank Barry Shein for a very good pro-Unix (or pro-both) posting. I'm generally pro-VMS (ie, DEC's "style" of doing things is closer to my own than the Unix authors' style is), but Barry's arguments were practical and carefully put.
steve@polyslo.UUCP (Steve DeJarnett) (03/04/88)
In article <295@dcc1.UUCP> douglas@dcc1.UUCP (Douglas B. Jones) writes: >Greetings: > >In article <1636@tulum.UUCP> hirai@swatsun.uucp (Eiji "A.G." Hirai) writes: >" While many observers have been expecting version 5.0 and the new VAX to be >released at the same time, there is a hint that Digital may release the new >machine under Ultrix, its Unix operating system, before the new VMS is ready, >which will probably be in June, according to one well-informed Digital >customer. > Sources say Digital sales representatives are being briefed not to be >surprised if, in the future, new systems are released first under Ultrix >and later under VMS." DEC was on campus here a few weeks ago trying to get us to buy VAXStations as opposed to Sun-3's. We weren't terribly interested, but we figured it was a good idea to hear them out, just in case they wanted to make us a beta-test site for something (no luck). The sales rep did say, however, that DEC is devoting more resources to Ultrix now than they ever did to VMS in the past (more engineers working on it at this time, more money spent on new development, and a greater commitment to Unix-in-general (tm?) in the future. Their hardware is still slow, but maybe they're coming around (slowly). For my $0.02 worth, go with Unix. I've used VMS, and it is relatively user-proof. However, if you are going to be doing ANY type of Software Development (besides 100-level Pascal programming, which I don't consider to be 'Software Development'), go with Unix. Whenever I try to program under VMS, I always say to myself: 'Gee, wouldn't it be great if I just had awk, or grep, or RCS, or make, or.....'. Now, granted, some of this stuff is available (some even for free), but you still can only go so far in making VMS a decent programming environment (resetting the prompt to '% ' and aliasing everything in sight to Unix-equivalent commands only fools your mind for so long). As far as real facts go, we too are locked in a battle with our Computer Center, trying to get them to support Unix for the campus so we can stop doing it (really embarrasing when the Computer Science Department has 10 unix machines capable of ~20 MIPS, and the Computer Center has about the equivalent horsepower in all of their Primes and (cringe) IBM's). Comp. Sci. here at Cal Poly is supporting the entire campus's Unix needs. Right now, I'd be happy to see our Center get a big VAX running VMS, just so we could pawn off the E-mail support to that (oh well, maybe some day). Doubt this helps much, but maybe you can glean something useful from it. Good luck. ------------------------------------------------------------------------------- | Steve DeJarnett | ...!ihnp4!csun!polyslo!steve | | Computer Systems Lab | ...!{csustan,csun,sdsu}!polyslo!steve | | Cal Poly State Univ. | ...!ucbvax!voder!polyslo!steve | | San Luis Obispo, CA 93407 | | ------------------------------------------------------------------------------- #include <std_disclaimer.h>
lm@arizona.edu (Larry McVoy) (03/04/88)
In article <717@cresswell.quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes: >In article <4080@megaron.arizona.edu>, lm@arizona.edu (Larry McVoy) writes: >> I agree with the rest of the article but this part is not completely >> true. VMS fortran is the de facto industry standard. Until I can have >> >If this is so, it would be interesting to know why Fortran 8X does not >resemble VMS Fortran. For example, both let you define record types, >but the syntax is very different. IBM's FORTVS doesn't seem to have >copied much from VMS Fortran either, I've carefully checked a recent >IBM Fortran manual and couldn't find any of the features that make >VMS Fortran so sexy. Apollo's Fortran hasn't any of the VMS extensions >that I know of. "de facto industry standard"? Maybe on Vaxen. And how many cycles do you think apollos spend chewing on fortran? Or ibm's? Let me put it this way: consider the type of people that use fortran. Look at what fortran those people use. Just because unix has f77 does not make it a fortran oriented machine (also read: f77 is not the selling point of unix). To beat a dead horse: would you buy an apollo to run fortran? Or a sun for that matter? Or an ibm? I think that you should ask fortran hackers what sort of fortran they want, not Unix/C hackers. -- Larry McVoy lm@arizona.edu or ...!{uwvax,sun}!arizona.edu!lm
landauer@morocco.Sun.COM (Doug Landauer) (03/04/88)
> As professionals, > it's always interesting to discuss what makes a good computer. The VMS > vs Unix holy war is unusually fun and enlightening because people > have such strong opinions and ideas about it. Besides, it's been at least six months since the last time this particular war erupted, so there's a whole new semester's worth of freshmen to be won! :-) Perhaps it's time to add this subject to the news.announce.newusers list of topics that have been rehashed so often that the net.vets are tired of it. (Or to add a new article to that suite, creating that list.)
levy@ttrdc.UUCP (Daniel R. Levy) (03/04/88)
In article <20268@bu-cs.BU.EDU>, bzs@bu-cs.UUCP writes: > Unix is the premiere system for compute intensive areas, such as the > sciences using Fortran. The reason is the vast range of power a > program written to run under Unix presents... [can be ported to machines > of different sizes] As a Death-starian, I heartily second the motion that the UNIX system is great :-) -- but NOT with FORTRAN, at least not on plain-vanilla UNIX systems. As you said yourself, the key phrase here is "compute intensive." I.e. you need all the crunch you can muster. Code compiled by /usr/bin/f77 is not all that marvelously efficient, to put it mildly. Of course the Cray people don't use /usr/bin/f77 :-) but if you're on a lesser machine it matters. (DEC now does sell a FORTRAN compiler for ULTRIX which is as good as its VMS version, and co$t$ about as much.) -- |------------Dan Levy------------| Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa, | an Engihacker @ | <most AT&T machines>}!ttrdc!ttrda!levy | AT&T Computer Systems Division | Disclaimer? Huh? What disclaimer??? |--------Skokie, Illinois--------|
awalker@topaz.rutgers.edu (*Hobbit*) (03/04/88)
Hmmph. The only reason DECNET would provide "security holes" is because someone didn't set it up correctly. Yes, you can fire off little almost- interactive processes to look around and do things, but a> if the rest of your system is properly "secured" you have nothing to fear, and b> you can disable this if you want anyway. Most VMS people let the default installation procedures set up their DECNETs for them, so they lose, but half an hour of dipping into the documentation can tell you what to be aware of. Yes, it's a bit off the track of unix-wizards, but y'awl shouldn't go around with the impression that DECNET is "at fault" just because it's there. _H*
ok@quintus.UUCP (Richard A. O'Keefe) (03/04/88)
In article <4125@megaron.arizona.edu>, lm@arizona.edu (Larry McVoy) writes: > And how many cycles do you think apollos spend chewing on fortran? Or > ibm's? Lots. When Apollo brought out their first machines, they were AEGIS/Pascal/Fortran machines. And yes, people do buy IBM mainframes and run Fortran on them. (Stop and think about 3090/VF.) I have heard of some large sales of PR1ME superminis to outfits that wanted to run particular (Fortran-coded) packages on them. If you're interested in Fortran cycles, ask who uses SPSS, who uses PAFEC, who uses GENSTAT, who uses ... > To beat a dead horse: would you buy > an apollo to run fortran? Or a sun for that matter? Or an ibm? I wouldn't buy an Apollo or a /370 myself, but if I had some Fortran to crunch, and the money to pay for it, I would certainly consider a Sequent. (Their Fortran doesn't look like VMS Fortran either.) If my business involved trying to write reasonably portable packages, VMS is the *last* thing I would use, precisely because it is so different from other Fortrans. And I would prefer a Sun to a VAX because I'd get better performance/price from it. > I think that you should ask fortran hackers what sort of fortran they > want, not Unix/C hackers. If ability to port existing code is the issue, what matters is what sort of Fortran they've _got_, not what they _want_. I'd suggest a survey of comp.lang.fortran, except that's likely to be biassed in favour of UNIX. Somewhere there must surely be published figures on relative Fortran usage of various machines. My point that Fortran 8X does not strongly resemble VMS Fortran remains unchallenged. I find it difficult to reconcile that with the claim that VMS Fortran is the "de facto industry standard".
roy@phri.UUCP (Roy Smith) (03/04/88)
lm@megaron.arizona.edu.UUCP (Larry McVoy) writes: > would you buy an apollo to run fortran? Or a sun for that matter? What's wrong with running fortran on a Sun? We do a lot of that; a 3/160 with FPA makes a damn nice number cruncher for the money. -- Roy Smith, {allegra,cmcl2,philabs}!phri!roy System Administrator, Public Health Research Institute 455 First Avenue, New York, NY 10016
bzs@bu-cs.BU.EDU (Barry Shein) (03/05/88)
Re: VMS fortran as "industry standard", reply to Larry McVoy et al. I think you miss my point (I don't particularly disagree with yours.) I claim Unix is the premiere scientific computing base, including fortran, because Unix runs on the machines scientists need while VMS doesn't. For example, high-end graphical workstations, Crays, ETA's (well, almost) etc. I can't imagine in this day and age that anyone needing compute-intensive cycles and/or data visualization looks towards VMS, 1..6MIPs on the whole architecture range just doesn't cut it anymore. I have no doubt that a lot of people who like fortran like VMS's fortran-like language (after all, you can extend the language just so much before you are leading your users down a garden path as they unwittingly use these "nice" features and lose all portability to other machines they may have access to.) Now, it's perfectly possible to write portable fortran code under VMS, I believe there's even some switch on the FORTRAN command to help check your code for non-standard statements. But of course, you're then back to the fortran language that's available on the other systems, so much for any advantages. And, in my experience, scientists and engineers have practical troubles with this, they seem frustrated that the VMS run-time library is not available for their code, let alone nuances of syntax. It can be a frustrating trap, I suppose one could argue that ignorance has its costs. Anyhow, to clarify my point once and for all: VMS has a nice (so some tell me) fortran devpt environment and a non-standard fortran which helps give it that reputation (and, I hear, a nice debugger.) My claims about Unix being superior for compute-intensive science was much more an observation that Unix runs on the full range of architectural performance needed by these scientists to get what they really want, results. Niceties are nice, but so are answers. It's possible it comes down to that I was talking about production and you're referring to devpt, although I claim that devpt is good enough under Unix (the differences are really not that huge) thus production should outweigh these advantages. -Barry Shein, Boston University
bzs@bu-cs.BU.EDU (Barry Shein) (03/05/88)
>As a Death-starian, I heartily second the motion that the UNIX system is >great :-) -- but NOT with FORTRAN, at least not on plain-vanilla UNIX systems. >As you said yourself, the key phrase here is "compute intensive." I.e. you >need all the crunch you can muster. Code compiled by /usr/bin/f77 is not all >that marvelously efficient, to put it mildly. Of course the Cray people >don't use /usr/bin/f77 :-) but if you're on a lesser machine it matters. >(DEC now does sell a FORTRAN compiler for ULTRIX which is as good as its VMS >version, and co$t$ about as much.) >-- >|------------Dan Levy------------| Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa, This (I believe, forgive me if I'm wrong) reveals a common fallacy. Yes, VMS/FORTRAN produces incredible Vax code, I have read it myself when running benchmarks for people, it is truly an impressive code generator. And yes, most vanilla F77's produce much less impressive code (although most Unix C compilers are about as good as VMS fortran, C presents some difficulties to code generators that Fortran doesn't.) The point is, however (eg), given $30K for a machine which would you rather run your code on? A Sun4 at about 10MIPs or a uVax at around 1MIP? Do you think any code generator will make up for that kind of difference? You can find similar arguments in every price range (and price ranges that don't exist in the Vax world, like Crays.) No code generator can make up for the real problem, locking yourself into the rather narrow, poor cost/performance of the Vax product. Give me a mediocre code-generator and real iron any day. I will say that Unix on a Vax makes the machine plausible again, or at least leads one into other issues. It's not completely vaxes I am complaining about (although I haven't bought one in many years, there was always something better to be had for my money, that could change, the 3000 series looks interesting), it's locking yourself into Vaxes for all computing (by choosing VMS) which seems like the losing strategy. -Barry Shein, Boston University
exodus@uop.edu (G.Onufer) (03/05/88)
VMS --- Just say NO!
mcginnis@uop.edu (Rogue Barbarian) (03/05/88)
In article <5586@elroy.Jpl.Nasa.Gov>, david@elroy.Jpl.Nasa.Gov (David Robinson) writes: > In article <68@musky2.MUSKINGUM.EDU>, terrell@musky2.MUSKINGUM.EDU (Roger Terrell) writes: > > VMS ADVANTAGES: > ... > > - VMS documentation blows UNIX documentation out of the water > > Huh?! VMS is VERY poorly documented if you want to do anything non-trivial. > They tend to only cover the obvious cases, and leave you to guess at the > complex cases. All sorts of things are hidden or undocumented. > The last job I had, at a Sililcon Valley Company, before I returned to school we used only VAX and VMS and I found that the VMS documentation was very inadequate for the needs of even a substandard programmer. There was no documentation on any higher system functions or programming. I prefer a UNIX enviorment and will, hopefully, not use VMS ever again. I'd rather use Ultrix. Richard W. McGinnis, Jr. (The Rogue Barbarian) UOP Gamemaster UUCP:{ucbvax, ucdavis, lll-crg, ptsfa!cogent, VMS Just say no..!! cepu!retix}!uop.edu!mcginnis or gamemaster Who would want my opinions? /earth is 98% full...rm -fr anyone you can.
msf@amelia.nas.nasa.gov (Michael S. Fischbein) (03/05/88)
In article <4125@megaron.arizona.edu> lm@megaron.arizona.edu.UUCP (Larry McVoy) writes: >In article <717@cresswell.quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes: >>In article <4080@megaron.arizona.edu>, lm@arizona.edu (Larry McVoy) writes: >>> VMS fortran is the de facto industry standard. Uhhh. No. ANSI FORTRAN 77 is the de facto and de jure industry standard. >Let me put it this way: consider the type of people that use fortran. Gee. We have a LOT of engineers, scientists, and general number crunchers using FORTRAN on machines ranging from PC's to Cray-2's. Many know no other computer language. We run a variety of operating systems too, including Unix and VMS. >Look at what fortran those people use. They use f77 if it is avaible on the machine in use. Otherwise, the program that does it's test cases so correctly on the VMS VAX doesn't compile, let alone run, on the Unix (sort of) Cray. Or on the VSOS Cyber. >Just because unix has f77 >does not make it a fortran oriented machine Nope. It is a general purpose operating system. >(f77 is not >the selling point of unix). No. Compatibility is. The fact that the same commands work on the workstation, the local mini, the minisuper, and the super is a tremendous convenience to the typical researchers who are not interested in the internal details of the machine -- they are interested in physics. >To beat a dead horse: would you buy >an apollo to run fortran? Or a sun for that matter? Or an ibm? Yes, we have. >I think that you should ask fortran hackers what sort of fortran they >want, not Unix/C hackers. They want standard fortran that runs the same on EVERY machine. mike -- Michael Fischbein msf@ames-nas.arpa ...!seismo!decuac!csmunix!icase!msf These are my opinions and not necessarily official views of any organization.
dsill@nswc-oas.arpa (Dave Sill) (03/05/88)
[I tried to sit on my hands when this thread got started, but this was the last straw.] > - VMS documentation blows UNIX documentation out of the water... Hah. The only thing the VMS manuals have over the man pages is bulk. I find them exceedingly verbose. If I want to read a novel, by golly I'll read a novel, but when I want to use a command, I want the facts. Not that there are no deficiencies in the man pages... > - The editors on VMS (TPU especially) are quite powerful. Hah, again. TPU is a half-baked attempt at an emacs-like editor. Fortunately, real emacs is available for just about every machine. But really, there is one difference between VMS and Unix that is so overwhelmingly important that it just can't be overemphasized, so I'll repeat it: VMS is proprietary, Unix is not. At any time, DEC can make any arbitrary decisions it wants to about the future of VMS. They could decide tomorrow to stop supporting it (of course they may have support contracts that they have to honor). What would happen if DEC went bankrupt? Or was bought out (however unlikely)? But nothing like this could happen to Unix. Unix is far bigger than any of the vendors supporting it. Yes even AT&T has limited power to change UNIX's destiny. So why put all your eggs in one basket and let somebody else hold it? ========= The opinions expressed above are mine. "The present-day computer world stinks. What we see out there is an unholy mess; thousands of incompatible files and programs created by artificial distinctions between program type." -- Ted Nelson
jay@unm-la.UUCP (Jay Plett) (03/05/88)
100%-|- | - | - VMS | - | - | - | - | - 50%-| + | + | + | + | + | + | + Ultrix | + 0%-|+________________________________________________________ | 1988 DEC's commitment to 2 operating systems, expressed as R&D budget, as sales effort, or in terms of just about any other parameter (The "50% in 1988" and the parameters cited are from statements attributed to Ken Olson in a recent Digital Review. The shape of the curve is pure guesswork). Anybody prognosticators want to extrapolate? -- Jay Plett UUCP: {cmcl2,ihnp4}!lanl!unm-la!jay {ucbvax,gatech}!unmvax!unm-la!jay ARPA: jxyp@lanl.gov
dan@maccs.UUCP (Dan Trottier) (03/05/88)
In article <310@nancy.UUCP> mcpherso@msudoc.UUCP (=P^ZAZPPPYPYXU zQYhBYPYo^O) writes: >Can we *please* stop the UNIX vs. VMS argument. We have both, we like >both. > ><flame on> > > YOU PEOPLE ARE WASTING MY TIME!!! > ><flame off> Oh come on now. There are ways in most of the news reader programs to kill all the articles with a certain subject line. I find these articles both informative, if not a little biased, and refreshing. We too have both UNIX and VMS on the campus and many of the arguments on both sides are valid. Many sites are faced with the problem of which operating system is best for their application. I hope that these articles can help them make the best choice. Just because *we* are established and happy doesn't mean that others are. The discussion has gone on longer than necessary but it is dying out. I suggest that if you don't want YOUR time WASTED and you use rn try the "k" command. -- A.I. - is a three toed sloth! | ...!uunet!mnetor!maccs!dan -- Official scrabble players dictionary -- | dan@mcmaster.BITNET
lenny@icus.UUCP (Lenny Tropiano) (03/06/88)
It basically comes down to the UNIX operating system works on a variety
of hardware choices, whereas, VMS does not. AT&T dedication to provide
for an OPEN ARCHITECTURE certainly gives UNIX a major plus. VMS is
(at least to my knowledge) limited to run on Digital's VAX family
(proprietary hardware, costing many $$$). Both OS' have their places
in different computing environments.
One might hope that someday both OS' can co-exist together on non-proprietary
hardware (much like MSDOS and UNIX). This might end the battle between
the OS'... Anyhow what do you expect the answer to be on a mostly *UNIX*
network, in the comp.unix.wizards group? Ask the same question on BITNET
or DEC's E-NET, or in comp.os.vms, and the answer most likely will be different.
-Lenny
--
US MAIL : Lenny Tropiano, ICUS Computer Group IIIII CCC U U SSS
PO Box 1 I C U U S
Islip Terrace, New York 11752 I C U U SS
PHONE : (516) 968-8576 [H] (516) 582-5525 [W] I C U U S
TELEX : 154232428 [ICUS] IIIII CCC UUU SSS
AT&T MAIL: ...attmail!icus!lenny
UUCP : ...{mtune, ihnp4, boulder, talcott, sbcs, bc-cis}!icus!lenny KEN%ORION.BITNET@cunyvm.cuny.edu (Kenneth Ng) (03/06/88)
>From: Dave Sill <dsill@nswc-oas.arpa> >Hah. The only thing the VMS manuals have over the man pages is bulk. >I find them exceedingly verbose. If I want to read a novel, by golly >I'll read a novel, but when I want to use a command, I want the facts. Unfortunately I am not yet fluent enough in VMS to comment on their manuals. Personally I'd rather have to wade through a lot of verbose junk to find the information I need, presuming of course that I do indeed find what I need. What I detest is documentation that lacks something that I need. What I find lack in the Unix manuals is a complete listing of the error messages and what they mean. Also lacking are all the variations. If I had the source code, I could use that, unfortunately I do not have such access. Examples are: what does error code 12 in make mean? I can't find any such mention in the man page. Also, the man page for read on timed reads do not indicate that the timed read will only work after the first character is typed. Yes I know that it is on the System 5 interface specs, but it should also be duplicated on the man page. Or at least a footnote suggesting looking into the Sys 5 interface specs. >But really, there is one difference between VMS and Unix that is so >overwhelmingly important that it just can't be overemphasized, so >I'll repeat it: VMS is proprietary, Unix is not. At any time, DEC can >make any arbitrary decisions it wants to about the future of VMS. >They could decide tomorrow to stop supporting it (of course they may >have support contracts that they have to honor). What would happen if >DEC went bankrupt? Or was bought out (however unlikely)? > >But nothing like this could happen to Unix. Unix is far bigger than >any of the vendors supporting it. Yes even AT&T has limited power to >change UNIX's destiny. A several years ago, Telenet and Uninet were two seperate companies offering x.25 packet service. We had them both here to access a computer conferencing system called EIES. Back then it was great because when one network went down, we could still be accessed through the other. We could also talk the reps into adding features and fixing bugs. Especially when we told them that the competition had those features or lacked those bugs. Now what does this have to do with Unix? A couple of years ago Telenet and Uninet merged, or one bought the other, I forgot. Since then, service has been gone downhill, since when one network went down the other went with it. And the new changes we suggested I believe have all been ignored. Therefore when I hear that Sun and AT&T are getting together, on one hand I say "It's about time", but I still remember what happened with the other merger. And reading that Apollo and other companies are worried about lockouts causes me even more concern. >So why put all your eggs in one basket and let somebody else hold it? Your eggs may be in many baskets, but is one hand picking up all the baskets? -- Kenneth Ng: ken@orion.bitnet ken@argus.uucp ken@mars.uucp ken@orion.njit.edu on bitnet, but not on arpanet.
mwm@violet.berkeley.edu (My watch has windows) (03/06/88)
>> Hah. The only thing the VMS manuals have over the man pages is bulk.
You forgot completeness and consistency. While they may be exceedingly
verbose, they are useable as reference manuals. The Unix man pages, on
the other hand, range from tutorials that are a pain in the ass to
find anything in, to brief scetches that don't do any more than remind
you of the flags.
I've as yet to run into a Unix system where the important part of the
documentation didn't live in the source tree.
Someone mentioned make. VMS has had "run" available for at least five
years. It does most of what make does (in other words, it handles the
important cases), and doesn't reuquire learning yet another language
to use. Run scripts look like (and are usuable as) DCL scripts.
On the other hand, there are lots of OS features - shared memory,
shared libraries, real IPC (as opposed to pipes), remote file systems,
and other interesting things for five years or more. These are things
that either don't exist, or have no standard, in Unix systems. At best
they have defacto standards.
I haven't seen VMS in five years. I assume that it's grown new
features since 3.x (or whatever it was I looked at). They may not be
clean, or neat, or as nice as they'll be when the eventually arrive in
Unix. But they're _there_. If you need them, Unix just won't cut it.
<mikelynn@engr.uky.edu (H. Lynn Tilley) (03/07/88)
In article <68@musky2.MUSKINGUM.EDU> terrell@musky2.UUCP (Roger Terrell) writes: > >VMS ADVANTAGES: > - VMS has a *friendlier* user interface than any variety of UNIX. Give UNIX a little time here. UNIX until recently was not sold by AT&T as a strong commercial competitor to MVS, CMS, VMS it is being sold in that light now and is going to evolve into a very friendly user interface. (Witness the recent agreement with IBM, AT&T and MicroSoft to develop a common user interface for DOS/OS2 UNIX and A/IX.) > - VMS is much more secure, ... Depends on whos' UNIX you are running. The term here is probably UNIX is a more open system than VMS which is very desirable in an university setting. Students are free to wander around the UNIX system, view all but the most confidental files, etc. This is a very big plus for computers in academics. It helps students understand their relationship to everyone else. > - VMS documentation blows UNIX documentation out of the water (someone >pointed out that you don't find VMS manuals in a bookstore; that is correct, >but it is not bad. As for finding them in the bookstore, remember this is a capitalist society. The books on UNIX are there because there is a very large UNIX market and therefore there is a lot of money to be made in UNIX help books, there is not much money to be made in the VMS help book market (not that people justing sitting down at the terminal of a VMS machine won't need as much help). >It is because VMS is so much larger and is designed for >a larger type of machine). UNIX is small, it's a marvel of compactness. That is one of the beauties of the system, it can grow with the size of your machine. UNIX is also extremely portable. The code is approximately 95% machine independent and requires very little effort to port to other architectures. UNIX, unlike any other operating system will run on everything from a PC to the biggest Cray. It is the only operating system that will run on everything that IBM makes (you don't call a 3090 and big machine). It is simpler to say, UNIX was not designed to run on *a* machine, it was designed to run on all machines. > - The editors on VMS (TPU especially) are quite powerful. Try emacs and a few of the other editors available for UNIX boxes. >UNIX ADVANTAGES: > - The UNIX shell "languages" are much better than DCL. >The thing that I prize VMS most for is its powerful software development >tools. UNIX is a better development system than VMS. UNIX provides a full featured programming langauge with its shell command set and awk. High level languages are used to provide specific interfaces where they do not already exist. These tools allow rapid program definition and prototype development. VMS program development is largely high level language based. Besides, UNIX was developed as a program development system, not a run-time system like VMS. Before I get flamed to badly let me fully acknowledge DEC's progess in this area. Their development system is good and it is getting better. Though the ability of Digital to support the programming staff for both Ultrix and VMS may soon come into question. Programming staffs are expensive and with the recent Ultrix debacle and massive standardization on SVID UNIXes, Digital has definitely got to redirect its efforts in the operating system market. Again, I think VMS is a good Operating system and it does have its place. Without getting to corney here, UNIX should not be thought of as an operating system, UNIX is a programming philosophy, thinking of it a merely an operating system sales UNIX short. -- | Henry L. Tilley UUCP: {cbosgd|uunet}!ukma!ukecc!lynn | University of Kentucky CSNET: lynn@engr.uky.edu V Engineering Computer Center BITNET: lynn%ukecc.uucp@ukma O voice: (606) 257-1752 ARPANET: lynn@a.ecc.engr.uky.edu
yuval@taux01.UUCP (Gideon Yuval) (03/07/88)
> The strongest single factor that Unix has going for it (in my > opinion) is that it runs on zillions of different kinds of hardware. We > used to run on pdp-11's and vaxes. Now we run mostly on Suns. Tommorow, > who knows? Maybe we'll buy a Sequent or an Alliant. Maybe PC's. The > common theme is that they are all Unix, making porting program and user > skills orders of magnitude easier than moving from one OS to another each The new ABI standard, which is supposed to be the Unix standard for object-code distribution, is (a variation of) COFF for SPARC. How much hardware-indpendence is going to survive the changeover to ABI? -- Gideon Yuval, +972-52-522255 (work), -2-690992 (home), yuval@taux02.nsc.com Paper-mail: National Semiconductor, 6 Maskit St., Herzliyah, Israel
jsloan@wright.EDU (John Sloan) (03/07/88)
in article <310@nancy.UUCP>, mcpherso@msudoc.ee.mich-state.edu (Mike McPherson) says: > Xref: wright comp.unix.wizards:5993 comp.os.vms:5749 > > Can we *please* stop the UNIX vs. VMS argument. We have both, we like > both. Perhaps I had better make my position clear, Mike. _We_ also have both Unix and VMS. I like both, and think each has its strengths and weaknesses, and areas of appropriate application. I happen to prefer Unix over anything I've ever used before since I started programming around 1970 (DOS/VS, OS/{MFT,MVT,SVS,MVS} on the IBM mainframe side, VMS since 2.x on the VAX side, INTERCOM/SCOPE on CDC Cybers, RSX and RT-11 on PDP-11s. CP/M in the Z80/S-100 days, CP/M-68K, MS/DOS, etc. as well as lots of Unixes), but that is a personal preference, as in politics, sex and religion, and arguments about any of these often generates more heat than light. I push Unix not for religious reasons but for purely economic ones. I am responsible for the deployment of systems and networks and for the management of what is arguably the largest computer center in our University (a matter of some dispute). I simply can not afford to deploy VAXen. I think VAXen are well designed, reliable machines. But I know, based on the numbers I see on the paperwork that crosses my desk, that I can provide more cost-effective computing by buying machines from Sun, Encore, NCR, H-P, what-have-you, than I can from DEC (or IBM for that matter). When I say "cost effective", I'm taking more than just the initial capital investment into account. It is my job to worry about retraining, reliability, power requirements, air conditioning requirements, compatibility, interoperability, maintenance, availability, expandability, preservation of existing investment, and a whole host of other "-ilities". Most of all, I worry about labor costs, because they are the highest of any of the costs I worry about: [1] the cost of my systems staff supporting a wide variety of machines in what is necessarily a multi-vendor environment, and [2] the cost of retraining users. "Users" includes graduate students who must be productive, because they're working on grant-funded projects with deadlines; and faculty researchers who we cannot afford to pay $40K-$70K a year to learn a new operating system and a new editor every time we deploy a new engine. When I look at capital costs, I see a whole lotta engines that are more cost effective than VAXen. And when I look at labor costs, I see an operating system that runs on a wide variety of machines, minimizing my costs for retraining my labor force. And when I look very very carefully, I notice to my delight that these cost effective machines just happen to all run this same operating system. Amazing! I have two VAXen, a 750 and a 785. I could not do with out them. But I could not have afforded to buy them, either. I inherited each, because, bless its heart, our industry provides absolutely no meaningful resale value on these machines, so usually they're cheaper to keep than to sell. Maintenance costs may shortly make that strategy invalid as well; I am on the verge of showing it's cheaper to replace our VAXen with Suns configured as timesharing engines, than to pay the maintenance costs over the expected remaining live cycle of these machines. It is not a matter of religion, Mike. It's a matter of money. And although if I am to believe what I read lately, that there is more than a tenuous connection between religion and money, at least here at my University in my Department, there is a clear cut strategy for providing adequate computing resources. -- John Sloan Wright State University Research Center CSNET: jsloan@SPOTS.Wright.Edu 3171 Research Blvd., Kettering, OH 45420 UUCP: ...!cbosgd!wright!jsloan (513) 259-1384 (513) 873-2491 Logical Disclaimer: belong(opinions,jsloan). belong(opinions,_):-!,fail.
avolio@decuac.dec.com (Frederick M. Avolio) (03/08/88)
In article <277@icus.UUCP> lenny@icus.UUCP (Lenny Tropiano) writes: >It basically comes down to the UNIX operating system works on a variety >of hardware choices, whereas, VMS does not. AT&T dedication to provide >for an OPEN ARCHITECTURE certainly gives UNIX a major plus. ... I am not going to argue VMS vs. U*ix because I do not use VMS. But my question is: given all the discussions in the press and on the net re: U*ix standards, holy and unholy alliances, etc., what gives you the impression you make in the above about dedication for providing an OPEN ARCHITECTURE? (Just curious what you have been reading that I haven't. My intention is not to start a vendor war. There are many vendors with good solutions...) Fred
rob@philabs.Philips.Com (Rob Robertson) (03/08/88)
In article <1179@uop.edu> mcginnis@uop.edu (Rogue Barbarian) writes: >I found that the VMS >documentation was very inadequate for the needs of even a substandard >programmer. There was no documentation on any higher system functions >or programming. I prefer a UNIX enviorment and will, hopefully, not >use VMS ever again. I'd rather use Ultrix. yeah, tell me another one. "With UNIX, if you're looking for something, you can easily and quickly check that small manual and find out that it's not there. With VMS, no matter what you look for -- it's literally a five-foot shelf of documentation -- if you look long enough it's there. That's the difference -- the beauty of UNIX is it's simple; and the beauty of VMS is that it's all there." --Ken Olsen, President of DEC ken's right. VMS IS well documented. Everything is in the manuals. Where it is is another story, but it's there. I have a funny feeling you did not have a COMPLETE set of VMS documentation (not only is it big, but expensive). I have a few problems with Ultrix documentation. There are also alot of DEC internal formats that ain't documented. Changing the "BUGS" section to "RESTRICTIONS" is something that really irks me. Why not call a spade a spade? And the removal of the "AUTHORS" sections is also a pisser. Alot of the berkeley stuff was done by midnight hackers whose only renumeration was being listed under the AUTHORS section. I'd rather use 4.3 BSD. rob william robertson rob@philabs.philips.com
mg@cidam.rmit.oz (Mike A. Gigante) (03/08/88)
In article <695@unm-la.UUCP>, jay@unm-la.UUCP (Jay Plett) writes: > [ graph deleted] > DEC's commitment to 2 operating systems, expressed as R&D budget, > as sales effort, or in terms of just about any other parameter > > (The "50% in 1988" and the parameters cited are from statements > attributed to Ken Olson in a recent Digital Review. The shape of > the curve is pure guesswork). > > Anybody prognosticators want to extrapolate? > -- > Jay Plett All this reminds me of the "unfailing committment (by DEC) to the continuation and development of its 36 bit family (Dec10, Dec20)" inspite of the evidence to the contrary. Not long after that statement, the replacement for the Dec10 (was it called Venus? Jupitor? some planet anyhow) was cancelled at rather short notice. I remember it well as we were replacing our aging KI10, the specs were written around DEC's data, then at the very last minute (i.e. just as we were to place the order), they cancelled the whole damn thing. At the time it was a real blow. (At my previous employer, not RMIT) Mike
gwyn@brl-smoke.ARPA (Doug Gwyn ) (03/08/88)
In article <497@taux01.UUCP> yuval@taux01.UUCP (Gideon Yuval) writes: >The new ABI standard, which is supposed to be the Unix standard for object-code >distribution, is (a variation of) COFF for SPARC. How much hardware-indpendence >is going to survive the changeover to ABI? I don't think this much matters. Few vendors of UNIX-derived systems have been using COFF (this is particularly true of those who started from a Berkeley base), and the only things this has mattered for are shared libraries, debuggers, and stand-alone development, none of which is important for application source portability. The only benefit of ABI would be binary portability among SPARC implementations; I suppose AT&T and Sun envision shrink-wrapped UNIX software for sale in the local supermarket. Somehow I doubt that most established computer manufacturers will want to give up their own architectures in favor of SPARC -- or is there some mathematical proof of its superiority? However, I could be surprised; there have been several instances of a manufacturer adopting an existing instruction set architecture (IBM 370, MC68000, DEC-10, VAX-11) for its own line of computers. For example, we have several Alliant FX/8s, which are fast implementations of the MC68000 instruction set (and even include MC680x0s for general-purpose (non-vector, non-parallel) processing).
siegel@hc.DSPO.GOV (Josh Siegel) (03/08/88)
In article <327@amelia.nas.nasa.gov> msf@amelia.nas.nasa.gov (Michael S. Fischbein) writes: >In article <4125@megaron.arizona.edu> lm@megaron.arizona.edu.UUCP (Larry McVoy) writes: >>In article <717@cresswell.quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes: >>>In article <4080@megaron.arizona.edu>, lm@arizona.edu (Larry McVoy) writes: >>>> VMS fortran is the de facto industry standard. > >Uhhh. No. ANSI FORTRAN 77 is the de facto and de jure industry standard. > > [ lots of stuff deleted ] I think both Sun and Encore are coming out with a VMS fortran. Also, Cray has its own drain bramaged version of fortran. ANSI is not the rule --Josh -- Josh Siegel (siegel@hc.dspo.gov) I like using a C-47A "puff dragon" to go hunting with.
wcs@ho95e.ATT.COM (Bill.Stewart.<ho95c>) (03/08/88)
:In article <1636@tulum.UUCP> hirai@swatsun.uucp (Eiji "A.G." Hirai) writes: :> Is VMS as horrible as I suspect or am I alone an thinking this? :>Please help shed the light for us! Please tell us what you think would be :>reasons why you wouldn't buy VMS! (or why you would). VMS may be evil, but it's not stupid (unlike IBM operating systeems.) The major difference is probably that UNIX is a development environment, while VMS is a production environment. Also, as Barry Shein points out, UNIX software can be used everywhere; VMS software is only useful on VAXen and a few VMS-imitators (some of the mini-supers). While UNIX does have portability problems, after any VMS version upgrade you can *hear* the applications breaking. There are features of VMS that I wish UNIX had (file versioning, batch process control, decent Fortran libraries), but you don't have as much flexibility for developing new software - and you could add these things to UNIX if you wanted; if you think adding real UNIX capability to VMS is easy, look at EUNICE and think some more. UNIX is a better environment for learning about computer systems, developing tools for non-computer problems, and generally having a good time. You should keep some VMS systems around - partly to expose your students to other systems, partly to let your fortran grinders grind fortran (though DEC may provide VMS fortran on ULTRIX as well as VMS). In article <68@musky2.MUSKINGUM.EDU> terrell@musky2.UUCP (Roger Terrell) writes: :We have both UNIX and VMS here at Muskingum, and my experience is that both :VMS ADVANTAGES: : - VMS is *friendly*; more so than any flavor of UNIX Yuk! VMS HELP is friendly, and VMS commands are a bit more consistent than UNIX's, but everything is so Clunky! Each level of a directory looks different, half the commands feel like JCL, and you can't just pop up a process to do something when you want it. I suppose the one other friendliness feature it has is DCL command-line editing, but I've used ksh long enough I've forgotten that vanilla sh users don't have it :-) : - the Run-time library that comes with VMS is extremely powerful and :is getting better still in the upcoming version of VMS (5.0). If you leave aside math libraries (which VMS does very well) I'd say UNIX does better. Some UNIX versions have shared libraries (which I assume VMS provides); these are a big win. : - VMS is much more secure, although this does not mean much in an Most of its security comes through obscurity, or through setting all the defaults to secure values. A tightly administered UNIX system can be just about secure, and *if you don't like things you can fix them* (well, assuming you've got source.) The recent NASA SPAN breakins were because a major VMS security bug was discovered (heck, the ink on the C-2 certification was hardly dry!) and it took DEC *months* to get around to installing the fix in Europe. : - The DEC compilers are VERY nice. Yep. : - VMS documentation blows UNIX documentation out of the water (someone No. VMS documentation blows V7 documentation out the water, at least for tutorial purposes. If you want user-friendly documentation, AT&T can probably out-weigh VMS documentation. But if you want to find something quickly, UNIX docs are better. (Admittedly, VMS HELP covers the equivalent of most of the things I look up in the manual.) : - The editors on VMS (TPU especially) are quite powerful. Foo. Look at most Emacsen. (I use vi, personally.) : - The UNIX shell "languages" are much better than DCL. This is largely because: : - UNIX has better facilities to deal with programs which use :more than one process. and : - Many text-oriented tools are available. : - UNIX has UUCP (and, therefore, Usenet) ** major plus here ** A mixed blessing, but it has its uses. -- # Thanks; # Bill Stewart, AT&T Bell Labs 2G218, Holmdel NJ 1-201-949-0705 ihnp4!ho95c!wcs # So we got out our profilers and debuggers and editors and various other # implements of destuction and went off to clean up the tty driver...
davidsen@steinmetz.steinmetz.UUCP (William E. Davidsen Jr) (03/08/88)
In article <497@taux01.UUCP> yuval@taux01.UUCP (Gideon Yuval) writes: >[...] >The new ABI standard, which is supposed to be the Unix standard for object-code >distribution, is (a variation of) COFF for SPARC. How much hardware-indpendence >is going to survive the changeover to ABI? I see that there is going to be a 386 standard, too, and perhaps others. The binary standard is only within the systems of one CPU family. -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs | seismo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
sommar@enea.se (Erland Sommarskog) (03/09/88)
Barry Schein goes along flaming against VMS and closes: >This is not a religious flame, I have presented myriad factual basis >for my arguments. VMS people like to claim religious flame and >"chocolate vs vanilla!" arguments. This is because they cannot deal Some of the "facts" are not just true, but Barry goes on as they were refutable. I shall comments some few points that I found wrong. (And, actually, I think Barry could make a good televangelist. :-) >Unix systems are relatively bundled, beyond mere hardware >considerations most Unix systems right out of the box are completely >useable. It can be supplemented in many significant ways with free or >nearly free (eg. ~$100 for an entire campus) software. VMS is heavily >unbundled, from day one if you want so much as a compiler you begin >layering heavy costs. And you'll pay a separate price for acquiring Now, watch it here. A Unix system comes with a bunch of compilers that's true. VMS does not. But what about the quality of the compilers? My experience of Unix compilers restricts to the Fortran and Pascal compiler that comes with 4.3 BSD on our VAX. The code they produce have a speed which hardly is acceptable for procduction. And if you want other languages, Ada for instance, you'll have to buy that separately also for Unix. >The claim that Unix is somehow less secure than VMS is a red herring. Ah, good televangelist preaching! >privilege you won't want to give to a user (I'm not sure I want to go >into the whole mess of the zillions of VMS "privilege" bits which >you'll never fully understand the implications of and will almost >surely end up giving away the store because some reasonable thing can >only be accomplished by giving a user some dangerous privilege bit, But, hey, you argue for Unix for that yuo can keep the security because you can have the source code. But with the same arguments you use against the VMS privilieges, can be used against the code: Will you ever fully understand it? Zillions of line of code. (Zillion seems to mean 30+ here.) >Unix's single privilege scheme [root or not root] is much more secure, >you just don't give out root privs and you know exactly what can and >cannot be done by the two sets of users on your system, who wants to >calculate the permutations of 30+ priv bits and what they might imply >singly and in combination?.) Sure. I also use one single screwdriver, no matter the size of the screws. Some of the screws get damaged, so what? It's much simpler that way. Seriuosly: The VMS privilieges makes it possible to just use those you need at the moment. And for giving away: Very few students ever need more than NETMBX and TMPMBX. They should have *very* good reasons for getting any other. >VMS. There's some on-line help in VMS but it's designed to sell >manuals or supplement them, the details are always missing >(purposely.) > >Most Unix systems come with on-line, complete manual sets with the >exact same text used to produce the printed manuals. Thus, what's the >cost to a student for Unix manuals? For $0 (zero) they can get This is a damned lie! If I look up the man-page for the Pascal compiler on our machine I learn about the compiler, but for the langauge as such I am referred to a separate document, which is not on the machine, at least the man- page gives me no reference. If you do HELP PASCAL on VAX machine you'll be able to get the most of the language definition. OK, the complete definition is in the orange binder, but you make it very good with the HELP facility. And for the Unix with the on-line help exactly as the printed ones: When you read from a terminal you're more likely to skim for certain information. Plunging through a long man-page is no fun. VMS' hierarical HELP is much better here. And this brings us on to another issue which Barry does not mention: Unix may have some clever tricks, but it's user interface is really arcane. One-letter options is certainly not state-of-the-art. I could continue, but I shall not. I think a campus should have some Unix systems since they are quite frequent in the real world. They should also have some non-Unix systems, since Unix systems are so frequent in the real world. The student should get more than one view. -- Erland Sommarskog ENEA Data, Stockholm sommar@enea.UUCP "Souvent pour s'amuser les hommes d'equipages and it's like talking to a stranger" -- H&C.
mike@turing.UNM.EDU (Michael I. Bushnell) (03/09/88)
All this VMS vs. UNIX discussion brings up an interesting thing I
heard recently:
DEC does its VMS development under Ultrix.
Wow! Of course, they can only do utilities and higher level libraries
this way, but it does say something about what the engineers that
actually WRITE VMS use!
Now, we all know that Ultrix isn't really UNIX, and that it probably
should be thrown out the window, but it is certainly a lot better than
VMS. At least thats what the writers of VMS think.
Michael I. Bushnell
mike@turing.unm.edu
{ucbvax,gatech}!unmvax!turing!mike
HASA -- "A" divisionram%shukra@Sun.COM (Renu Raman, Taco-Bell Microsystems) (03/09/88)
In article <3347@briar.Philips.Com> rob@philabs.Philips.Com (Rob Robertson) writes: >I have a few problems with Ultrix documentation. There >are also alot of DEC internal formats that ain't documented. Changing >the "BUGS" section to "RESTRICTIONS" is something that really irks me. >Why not call a spade a spade? And the removal of the "AUTHORS" >sections is also a pisser. Alot of the berkeley stuff was done by >midnight hackers whose only renumeration was being listed under the >AUTHORS section. I'd rather use 4.3 BSD. > >rob Do you think Ken would have liked to see while logged into an ultrix machine: "man csh" and see AUTHOR Bill Joy Naah. :-) :-) :-) Sequent manuals have been more faithful with regard to author sections. Some pages where Sun manuals have removed references (vmstat comes to my mind - AUTHORS - Joy & Ozalp Babaoglu) sequent has faithfully reproduced. Maybe Bill removed those references.
rk@lexicon.UUCP (Bob Kukura) (03/10/88)
Posting-Front-End: GNU Emacs 18.41.8 of Thu Feb 4 1988 on fear (berkeley-unix) In article <867@unmvax.unm.edu> mike@turing.UNM.EDU (Michael I. Bushnell) writes: > Now, we all know that Ultrix isn't really UNIX, and that it probably > should be thrown out the window, but ... I use Ultrix every day and I didn't know this! I don't claim to be a unix.wizard, but I do manage to run an nfs-based network of Ultrix-running vaxes in addition to my regular software-engineering tasks. Why is Ultrix not really UNIX? It seems, based mainly on what I read on the net, that Ultrix isn't that different than any other vendor's attempt at providing a usable product based on Berkeley Unix that is also somewhat Sys V compatible. We've never had porting problems attributable to Ultrix being different than BSD Unix. My only regret is that my name and address is on every VMS-system-manager mailing list, and I have to sort through countless ads for products designed to fix/hide/extend/replace/improve VMS. We have been a satisfied DEC Ultrix customer for over three years now, and, by using the word 'Ultrix' in every sentence of every conversation with every sales, support, and service representative from DEC, have managed to avoid any serious discrimination from them. We have even recently expanded our system in a very cost-effective manner - by adding Microvax 2000s, each supporting 8 users for about $10k. I don't work for DEC - just a satisfied customer. -- -Bob Kukura uucp: {husc6,linus,harvard,bbn}!spdcc!lexicon!rk phone: (617) 891-6790
wesommer@athena.mit.edu (William Sommerfeld) (03/10/88)
In article <249@lexicon.UUCP> rk@lexicon.UUCP (Bob Kukura) writes: >In article <867@unmvax.unm.edu> mike@turing.UNM.EDU (Michael I. >Bushnell) writes: > >> Now, we all know that Ultrix isn't really UNIX, and that it probably >> should be thrown out the window, but ... . >Why is Ultrix not really UNIX? Ultrix 1.1 and 1.2 were pretty much vanilla 4.2 and "4.2 1/2" BSD. Ultrix 2.x contains a large number of really gratuitous changes, and still doesn't include things from 4.3BSD (such as the use of the domain name resolver instead of host tables) which are an _absolute necessity_ for large networked environments. Source code is difficult to obtain, and (a) doesn't always correspond to the binaries they ship and (b) doesn't always correspond to a working version. The way they implement the "clean" bit in filesystem headers is incompatible with Berkeley 4.3. There is an unused "fs_clean" bit allocated in the Berkeley FFS superblock. Instead of using this, they used the "fs_fmod" field. As a result of this, if you mount an Ultrix 2.0 filesystem read-only on a BSD system, the BSD system will panic in about 30 seconds with "rofs mod". This may not seem to be a major issue to some people, but it was to us. There are some really gross modularity violations; in particular, if you try to mount a "dirty" filesystem before running fsck on it, the _KERNEL_ prints a message on the controlling terminal of the process doing the mount system call, telling the user to 'run /etc/fsck'. What happened to error codes? C'mon guys, it would have been much better to just fix the error returns from the mount system call so that you can figure out the difference between "nonexistant device" and "file system dirty" and "superblock has bad magic number" and ... The kernel is _huge_, about twice the size of the 4.3BSD+NFS kernel which we use. DEC doesn't care that they added 100KB to the size of the kernel just to support asymmetric multiprocessing. And DEC doesn't care that you need at least 3 MB of memory to run it: they're in the business of selling memory upgrades, too. Never mind. If DEC doesn't throw out the VAX architecture, they're going to be out of business in a few years, anyway. Athena looked at Ultrix 2.x, and ditched it in favor of 4.3+NFS (the University of Wisconsin port, specifically) because it was too buggy and too hard to fix. We haven't had any real trouble with field service, but then we've got a DEC field service engineer on-site pretty much full time; he has been "educated" to deal with our systems. We also have sufficient clout with DEC to be able to correct some of their misconceptions. Athena finally got the Ultrix 2.0 source after Paul Grey (president of MIT), complained to Ken Olsen (president of DEC) that DEC was getting in the way of Athena by stalling the licensing negotiations. Bill Sommerfeld MIT Project Athena.
ganek@apollo.uucp (Dan Ganek) (03/10/88)
> All this VMS vs. UNIX discussion brings up an interesting thing I > heard recently: > > DEC does its VMS development under Ultrix. > > Wow! Of course, they can only do utilities and higher level libraries > this way, but it does say something about what the engineers that > actually WRITE VMS use! > > Now, we all know that Ultrix isn't really UNIX, and that it probably > should be thrown out the window, but it is certainly a lot better than > VMS. At least thats what the writers of VMS think. > > > > Michael I. Bushnell > mike@turing.unm.edu > {ucbvax,gatech}!unmvax!turing!mike > > HASA -- "A" division > > You forgot the :-), right? It's been a few years since I've worked at DEC; but I doubt that there's a single ULTRIX machine within 10 miles of Spit Brook Rd. (I would also assume that the ULTRIX people put in check for the BLISS compiler and core dump when someone tries to use it! :-) /dan
wesommer@athena.mit.edu (William E. Sommerfeld) (03/11/88)
In article <3ac56669.c82a@apollo.uucp> ganek@apollo.uucp (Dan Ganek) writes: >It's been a few years since I've worked at DEC; but >I doubt that there's a single ULTRIX machine within >10 miles of Spit Brook Rd. Well, considering that I was just invited to a College Night for graduating seniors at the Ultrix Workstation Group at their facility on Spit Brook Road in Nashua, I think you're wrong.
wortley@hwee.UUCP (Tim Wortley) (03/11/88)
In article <12149@brl-adm.ARPA> KEN%ORION.BITNET@cunyvm.cuny.edu (Kenneth Ng) writes: >>Hah. The only thing the VMS manuals have over the man pages is bulk. >>I find them exceedingly verbose. >Unfortunately I am not yet fluent enough in VMS to comment on their >manuals. Personally I'd rather have to wade through a lot of verbose Can't say I'm that fluent either, however, at least when I login, I can rely on being about to look up a manual page, and finding *most* of the information I am looking for. Over here on our split campus site ( or rather this departments here, rest university somewhere else ) I have access to **one** DEC VAX manual - and thats not on VMS itself, but on various "addon" applications ( I think the "DEC C" manual is there also ). Of course it means signing it out, with deposit...... Also, I have yet to find a VMS related book *anywhere*, mind you, give our library it's due, the Main Vaxcluster was only installed a year ago! > >>But really, there is one difference between VMS and Unix that is so >>overwhelmingly important that it just can't be overemphasized, so >>I'll repeat it: VMS is proprietary, Unix is not. One thing to remember, VMS *IS* a competitor to UN*X, ask yourselve this question, would unixs' be as good if there wasn't a rival operating system. The last thing any of us would want, is the dieing of VMS. We can still learn lots from it ( How not to design a system??? :-) As you've probably guessed from above, I'm quite impartial! I only use our VaxCluster/VMS because no-one else does, and it's local terminal room is warm and quiet! ttfn Tim ---------------------------------------------------------------------------- Tim Wortley JANET: wortley@uk.ac.hw.ee Dept Elec & Elec Eng. UUCP: uunet!mcvax!ukc!hwcs!hwee!wortley Heriot-Watt Univ. ARPA: wortley@ee.hw.ac.uk Edinburgh, Scotland. or: wortley%ee.hw.ac.uk@uk.ac.ucl.cs.nss
avolio@decuac.dec.com (Frederick M. Avolio) (03/11/88)
In article <3ac56669.c82a@apollo.uucp> ganek@apollo.uucp (Dan Ganek) writes: >It's been a few years since I've worked at DEC; but I doubt that > there's a single ULTRIX machine within 10 miles of Spit Brook Rd. You have been away long... Actually there are probably over a hundred ULTRIX machines at Spitbrook Road (counting workstations) since UNIX Engineering is in the same building as VMS Engineering. (Of course, they are required to eat in separate facilities :-) ). Fred
dave@garfield.UUCP (David Janes) (03/12/88)
In article <695@unm-la.UUCP> jay@unm-la.UUCP (Jay Plett) writes: | 100%-|- | | - | | - VMS | | - | | - | | - | | - | | - | 50%-| + | | + | | + | | + | | + | | + | | + Ultrix | | + | 0%-|+________________________________________________________ | | | 1988 This is obviously a plot by DEC. dave -- UUCP: {utcsri,ihnp4,allegra,philabs}!garfield!dave CDNNET: David Janes <dave@garfield.mun.cdn> BITNET: dave@mun
dricej@drilex.UUCP (Craig Jackson) (03/12/88)
One reason why these Unix vs VMS wars come up so much is that they're fun.
Anyway, here's my perspective: For a university, quite likely that Unix
is better. A university is likely to be able to get technical talent
cheaper and to have more of it. It is also less likely to be doing
large-scale computing, with lots of disk, tapes, etc.
I think that VMS's real strength is in the latter area. It isn't as
oriented toward mongo Data Processing as IBMs, etc are, but it has
better facilities than Unix. VMS also becomes a real choice if you have
to do a lot of record-oriented I/O--something that Unix hates.
When I mean mongo, I mean when you get the 33rd Eagle or the 16th tape
drive... :-)
Sure, there are Unices which handle such things. But the mainstream
of Unix doesn't; you've lost the 'non-proprietary' nature of Unix when
you go this direction.
--
Craig Jackson
UUCP: {harvard!axiom,linus!axiom,ll-xn}!drilex!dricej
BIX: cjacksonallbery@ncoast.UUCP (Brandon Allbery) (03/12/88)
As quoted from <733@cresswell.quintus.UUCP> by ok@quintus.UUCP (Richard A. O'Keefe): +--------------- | My point that Fortran 8X does not strongly resemble VMS Fortran remains | unchallenged. I find it difficult to reconcile that with the claim that | VMS Fortran is the "de facto industry standard". +--------------- If there is a de-facto industry standard, it would be IBM. NOT VMS. -- Brandon S. Allbery, moderator of comp.sources.misc {well!hoptoad,uunet!hnsurg3,cbosgd,sun!mandrill}!ncoast!allbery
irf@kuling.UUCP (Bo Thide) (03/12/88)
In article <2258@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: >In article <284@wright.EDU> jsloan@wright.EDU (John Sloan) writes: >>DEC has delivered a >>proposal for a 6MIPS VAX for $1.2M. Six months ago I purchased, >>received, and deployed our Sun-3/280S, a 4MIPS engine for under >>$100K. Well, I just got my FPA installed in my HP9000/350 (multi-user HP-UX) turning this 4 MIPS machine (4.7 times VAX integer, they say) into a 3.5 MWhets number cruncher. This is an amazing speed at an amazingly low total price (less than the equivalent of $50k for the lot). I am just now installing an Ariel FFT processor (at $1,600) to improve the speed even further (1024 point complex FFT in 9 ms, 256 point real FFT in less tan 1 ms). Similar workstations are available from Sun, Apollo, Masscomp and others. This just shows that today's personal "super"-workstations have turned traditional minis (like the VAXen) obsolete. An added benefit is that all workstations use (some type of) UN*X. -Bo -- >>> Bo Thide', Swedish Institute of Space Physics, S-755 90 Uppsala, Sweden <<< Phone (+46) 18-300020. Telex: 76036 (IRFUPP S). UUCP: ..enea!kuling!irfu!bt
allbery@ncoast.UUCP (Brandon Allbery) (03/13/88)
As quoted from <12152@brl-adm.ARPA> by mwm@violet.berkeley.edu (My watch has windows): +--------------- | On the other hand, there are lots of OS features - shared memory, | shared libraries, real IPC (as opposed to pipes), remote file systems, | and other interesting things for five years or more. These are things | that either don't exist, or have no standard, in Unix systems. At best | they have defacto standards. +--------------- ?! I know that all you folks consider non-BSD Unixes to not be Unix, but these and other features are all in System V Release 3, which (believe it or not) IS a standard. So why are you all comparing VMS to an OS which doesn't support record locking and is schizoid over how to use shared memory? ;-) [Hey AT&T: shared memory might be a pain to attach to the filesystem, but message queues make sense there. But please add something like msg_qnum to file operations rather than forcing the O_NDELAY braindamage on messages. AND MAKE poll() WORK ON NON-STREAMS!!!] -- Brandon S. Allbery, moderator of comp.sources.misc {well!hoptoad,uunet!hnsurg3,cbosgd,sun!mandrill}!ncoast!allbery
mangler@cit-vax.Caltech.Edu (Don Speck) (03/14/88)
In article <1636@tulum.UUCP> hirai@swatsun.uucp (Eiji "A.G." Hirai) writes: > This person [in charge of computing services] has in mind buying Vaxes > with VMS, and DECnet with lots of money... In 1979, Caltech's computing center replaced its DECsystem-10 with a pair of Vaxes. All the users were horrified at the cost of CPU time, so one by one the departments bought vaxen of their own, and by 1986 none of the departments needed the computing center. The computing center's vaxes were sold, the operators fired, and they were out of business. Do you think it even mattered whether they ran VMS or Unix? (They ran a Unix emulator on top of VMS). They went out of business not because of their software, but because most departments could afford the same kind of machines and run them to suit their own priorities. What they were running did not benefit from being centralized. Computing centers came about in the days when no virtually no department could justify any useful-sized computer on their own. The closest modern analog is the supercomputer. A computer center should concern itself with providing services which benefit from being centralized because they're expensive or require trained and/or round-the-clock personnel. Things like supercomputers, your campus LAN backbone, network gateways, mail servers, news servers, disk servers, backup servers, phototypesetters, color laser printers, obtaining campus-wide licenses and maintaining sources archives. Things that you tend to want very few of, rather than many. Don Speck speck@vlsi.caltech.edu {amdahl,ames!elroy}!cit-vax!speck
bin@rhesus.primate.wisc.edu (Brain in Neutral) (03/15/88)
From article <2505@decuac.DEC.COM>, by avolio@decuac.dec.com (Frederick M. Avolio):
< In article <3ac56669.c82a@apollo.uucp> ganek@apollo.uucp (Dan Ganek) writes:
<
<>It's been a few years since I've worked at DEC; but I doubt that
<> there's a single ULTRIX machine within 10 miles of Spit Brook Rd.
<
< You have been away long... Actually there are probably over a hundred
< ULTRIX machines at Spitbrook Road (counting workstations) since UNIX
< Engineering is in the same building as VMS Engineering. (Of course,
< they are required to eat in separate facilities :-) ).
<
< Fred
Separate bathrooms, too?pes@ux63.bath.ac.uk (Smee) (03/17/88)
In article <867@unmvax.unm.edu> mike@turing.UNM.EDU.UUCP (Michael I. Bushnell) writes: > >All this VMS vs. UNIX discussion brings up an interesting thing I >heard recently: > > DEC does its VMS development under Ultrix. > >Now, we all know that Ultrix isn't really UNIX, and that it probably >should be thrown out the window, but it is certainly a lot better than >VMS. At least thats what the writers of VMS think. Well, what that *actually* shows is that the writers of VMS think that a Unix-like environment is better than VMS FOR DEVELOPING SYSTEM SOFTWARE. This meshes with my own view that Unix is a very good, and powerful, system for computer programmers to use -- but that it is not really very friendly for 'naive' users. (They're the ones who aren't interested in computers as such, but simply want to use them as tools to solve problems in their own fields; frequently using 'brought-in' packages because they don't like to, or can't, program.) Fortunately (for us computer bods) this fact, coupled with the popularity of Unix, ensures lots of jobs for Unix programmers to produce user-friendly wrappers or shells. One of the more popular defenses of Unix is that 'well, it's easy to provide user-friendly tailored environments'. I'd say that ideally you shouldn't need to. (I think that the goal of Computer People should be a system that *IS* friendly to everyone, rather than a system which can be made to be friendly to everyone. Tricky? Sure. That's why we get paid so well. A tailorable system -- like Unix -- is a good first step, but it's ONLY a first step.) (Before all you Unix fans out there leap on me, read the original Bell Journal articles about the development of Unix. The authors explicitly stated that their intent was to produce a powerful tool FOR SYSTEM PROGRAMMERS. They (and I) think they succeeded. If I'm being heretical, then so are they.) (Further PS -- I don't much care, personally, for VMS. What I'm objecting to is the original implied comparison, which is silly. It's like saying that because the folks who built your house used a crane to bring in the bricks, therefore you should use one to bring in your shopping. And, I've become quite fond of Unix; I just don't think that it (or any other O/S) is a magic solution for all problems. Keep a sense of perspective.) All meant in the friendliest possible way. I think we do better if we don't become too locked into a particular framework of ideas... Cheers, Paul
allbery@ncoast.UUCP (Brandon Allbery) (03/17/88)
As quoted from <3347@briar.Philips.Com> by rob@philabs.Philips.Com (Rob Robertson): +--------------- | are also alot of DEC internal formats that ain't documented. Changing | the "BUGS" section to "RESTRICTIONS" is something that really irks me. | Why not call a spade a spade? And the removal of the "AUTHORS" +--------------- Uh, that's why it was changed -- so they *would* call a spade a spade. Unless BSD programs are all broken relative to System V (unlikely), the so-called "bugs" section usually points out restrictions of a program's implementation, NOT fixable bugs. "Fixing" them would require a totally different algorithm for the program, and in many cases there aren't any candidates for a better one. If you don't believe me, go write a "fixed" version of one of them. The Unix manuals are at least honest in pointing out the shortcomings of the programs. Do VMS manuals tell you about pathological cases? (I haven't seen any VMS manuals, but I know that the TOPS-20 manuals I saw didn't mention them; nor do manuals for IBM's VM/SP or for other operating systems I've had the chance to look over.) -- Brandon S. Allbery, moderator of comp.sources.misc {well!hoptoad,uunet!hnsurg3,cbosgd,sun!mandrill}!ncoast!allbery
lynn@engr.uky.edu (H. Lynn Tilley) (03/18/88)
In article <4583@garfield.UUCP> dave@garfield.UUCP (David Janes) writes: >In article <695@unm-la.UUCP> jay@unm-la.UUCP (Jay Plett) writes: >| 100%-|- >| | - >| | - VMS >| | + Ultrix >| | + >| 0%-|+________________________________________________________ >| | >| 1988 > >This is obviously a plot by DEC. > Actually not, Last year Digital spent more on Ultrix development than they did on VMS. They really no longer have a choice, UNIX is pushing VMS out of the market place and Digital sees the light at the end of tunnel. Despite what the VMS defenders like to say, RISC is here and VMS is not projected to be compatible across this architecture. If this is true (I have heard this from a couple of different source, none at DEC though) Digital is faced with a choice of maintaining PDP and MICROVAX technology (which even by todays standards is very expensive compared to the power you get with it) or going to new technology which will largely mean the abandonment of VMS and any VMS services that can not be supported under Ultrix. Now as I have said, I have heard this from a couple of different sources and since I am in the process of planning equipment purchases for the next two to three years I would like to know if it is a valid assessment of VMS's future. -- | Henry L. Tilley UUCP: {cbosgd|uunet}!ukma!ukecc!lynn | University of Kentucky CSNET: lynn@engr.uky.edu V Engineering Computer Center BITNET: lynn%ukecc.uucp@ukma O voice: (606) 257-1752 ARPANET: lynn@a.ecc.engr.uky.edu
chris@mimsy.UUCP (Chris Torek) (03/20/88)
In article <2134@ukecc.engr.uky.edu> lynn@engr.uky.edu (H. Lynn Tilley) writes: [It is rumoured that] >... RISC is here and VMS is not projected to be compatible across >this architecture. ... [could] mean the abandonment >of VMS and any VMS services that can not be supported under Ultrix. This gave me a funny thought. If you have seen Ultrix 2.x, you know that it `looks more like VMS' than did 4.2BSD. Perhaps the plot runs thus: Hack Ultrix until it smells enough like VMS to get most customers to switch. Is that a DCL shell I see in 3.0? :-) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
roy@phri.UUCP (Roy Smith) (03/20/88)
lynn@engr.uky.edu (H. Lynn Tilley) writes: > Despite what the VMS defenders like to say, RISC is here and VMS is not > projected to be compatible across this architecture. If I understand Henry correctly, he's saying that you can't port VMS to a RISC machine. Why not? Other than it's proprietary nature, what is there to prevent a VMS port hardware other than a vax? -- Roy Smith, {allegra,cmcl2,philabs}!phri!roy System Administrator, Public Health Research Institute 455 First Avenue, New York, NY 10016
dhesi@bsu-cs.UUCP (Rahul Dhesi) (03/21/88)
In article <3201@phri.UUCP> roy@phri.UUCP (Roy Smith) writes: > If I understand Henry correctly, he's saying that you can't port >VMS to a RISC machine. Why not? Other than it's proprietary nature, what >is there to prevent a VMS port hardware other than a vax? The VAX/VMS kernel seems to be written in some combination of assembly language and the high-level language BLISS. But BLISS is a machine- dependent language. The basic design of VMS is heavily dependent on the VAX architecture. The four VAX CPU modes (kernel, executive, supervisor, user) are everywhere assumed to exist and the security of the system relies on having these modes available. System calls assume the existence of a VAX-specific trap mechanism. Even specific address bits are assumed (I believe the high bit in the address distinguishes between user address space and system address space). Take a look at the VAX/VMS Internals handbook, and compare it with the UNIX design book by Bach. The VMS book is chock-full of information about how specific VAX registers are used and how things are pushed and popped on the stack by instructions to change mode to kernel etc., how address bits are used, how hardware-dependent tricks are used to achieve this or that. The UNIX book, on the other hand, says nothing about the hardware. The difference in philosophy is clear. The concept of separating a small machine-dependent part and a large machine-dependent part and rewriting only the small machine-dependent is foreign to VAX/VMS. Making VMS work on a non-VAX architecture would not be a port. It would be a rewrite from the ground up. VMS is an efficient, specialized dinosaur that will become extinct when the climate changes, and the climate is changing. -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesi
grr@cbmvax.UUCP (George Robbins) (03/21/88)
In article <2134@ukecc.engr.uky.edu> lynn@engr.uky.edu (H. Lynn Tilley) writes: > In article <4583@garfield.UUCP> dave@garfield.UUCP (David Janes) writes: > >In article <695@unm-la.UUCP> jay@unm-la.UUCP (Jay Plett) writes: > >| 100%-|- > >| | - VMS > >| | + Ultrix > >| 0%-|+________________________________________________________ > >| 1988 > > > >This is obviously a plot by DEC. > > > Actually not, Last year Digital spent more on Ultrix development than > they did on VMS. They really no longer have a choice, UNIX is pushing > VMS out of the market place and Digital sees the light at the end of tunnel. Yeah, sure. A piece of sales literature showed up here the other day, extolling the virtues of replacing 7xx's with 88xx's. "All VAX systems, including the VAXBI systems use VMS as the operating system of choice. There is minimal user and operator retraining-Investment protection again. Remember, too, VMS will also increase the ease of transporting third party software or customer developed applications. Digital is a full-service company providing software consulting servie and training in all VAX systems to simplify all migrations." Nowhere in the brochure did the the words Unix or Ultrix appear. Why be simplistic? DEC is investing in the Unix area because a significant portion of DEC systems are being sold to customers that are demanding/requiring Unix. DEC isn't willing to give up that market share so they are making a reasonable effort to meet customer desires. This doesn't mean that they are giving up on VMS, or trying to make Ultrix look enough like VMS to trick their customers. For an interesting parallel, look at the evolution and persistance of the RSTS-11 operating system. > Despite what the VMS defenders like to say, RISC is here and VMS is not > projected to be compatible across this architecture. If this is true > (I have heard this from a couple of different source, none at DEC though) This is a farily common story, however just because porting VMS to some particular RISC architeture may have been a problem, doesn't mean that the VMS software architecure, services and user interface can't be implemented on a machine that isn't VAX object code compatible. -- George Robbins - now working for, uucp: {uunet|ihnp4|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@uunet.uu.net Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
grr@cbmvax.UUCP (George Robbins) (03/21/88)
In article <10720@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: > > This gave me a funny thought. If you have seen Ultrix 2.x, you know > that it `looks more like VMS' than did 4.2BSD. Perhaps the plot runs > thus: Hack Ultrix until it smells enough like VMS to get most customers > to switch. Huh? If Ultrix 2.x is more like VMS than Ultrix 1.x, it's going to take DEC 10 years to do the trick. That's not to say that won't try to provide some kind of VMS emulation environment, but the biggest changes in 2.x are to make VAXes and VAX workstations more or less competitive with the random unix oriented hardware providers. This is mostly spelled Sun compatible networking/NFS, workstation support and X-windows. -- George Robbins - now working for, uucp: {uunet|ihnp4|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@uunet.uu.net Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
sef@csun.UUCP (Sean Fagan) (03/21/88)
In article <3201@phri.UUCP> roy@phri.UUCP (Roy Smith) writes: >lynn@engr.uky.edu (H. Lynn Tilley) writes: >> Despite what the VMS defenders like to say, RISC is here and VMS is not >> projected to be compatible across this architecture. > If I understand Henry correctly, he's saying that you can't port >VMS to a RISC machine. Why not? Other than it's proprietary nature, what >is there to prevent a VMS port hardware other than a vax? Nothing. In fact, if you look into an Elxsi, you'll see that they (claim) to be source-code compatable with VMS, and have their own DCL-like shell (seems to be pretty good, execpt that something like 'FORTRASH <File>' works under VMS and not under ECL [Elxsi's Command Line thingamajig; the whole works are known as EMS]). I don't know how valid their claims are, but they do have a fast machine, lots of processors, runs Unix (both versions), their VMS close, and their own OS (all at the same time). Of course, binaries don't work, but they're trying to get as many people as possible to recompile as possible. MACRO-32 won't work, either. Of course, I have know affiliations with Elxsi other than the fact that I want one of their machines for a PC. >Roy Smith, {allegra,cmcl2,philabs}!phri!roy -- Sean Fagan uucp: {ihnp4,hplabs,psivax}!csun!sef CSUN Computer Center BITNET: 1GTLSEF@CALSTATE Northridge, CA 91330 (818) 885-2790
chris@mimsy.UUCP (Chris Torek) (03/21/88)
>In article <10720@mimsy.UUCP> I wrote: >>... Perhaps the plot runs thus:... In article <3486@cbmvax.UUCP> grr@cbmvax.UUCP (George Robbins) writes: >Huh? I was (mainly) kidding. Apparently your leg came off in my hand. I would not be surprised to see a `VMS environment' in some future Ultrix, however---not VMS itself but something that lets VMS folks feel comfortable. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
kerr@oodis01.ARPA (Kerr) (03/21/88)
Our local DEC salesperson tells us that in the last 6 months DEC has shipped more systems with unix than vms. -- Grant Kerr Control Data Corporation INTERNET: kerr@oodis01.arpa UUCP: ihnp4!lll-tis!oodis01!kerr
paul@unisoft.UUCP (n) (03/21/88)
In article <3201@phri.UUCP> roy@phri.UUCP (Roy Smith) writes: > > If I understand Henry correctly, he's saying that you can't port >VMS to a RISC machine. Why not? Other than it's proprietary nature, what >is there to prevent a VMS port hardware other than a vax? > LARGE chunks of it are written in assembly .... the VMS kernel is actually very elegant (and Vax based) internally (the user interface as we all know stinks). The story goes that they had the base kernel running on a simulator before they ever got the architecture finished (they had to know what context to save in the process switch instructions etc). VMS even does some things BETTER than Unix (especially signals - of course they use hardware support ....) Paul PS: don't flame me I've hacked VMS internals for 3 years and Unix for the last 4 so I have a fairly balanced experience a reasonably -- (C) Copyright Paul Campbell, you only may redistribute if your recipients can. E-mail: ..!{ucbvax,hoptoad}!unisoft!paul Nothing here represents the opinions of UniSoft or its employees (except me) "Nuclear war doesn't prove who's Right, just who's Left" (ABC news 10/13/87)
gwyn@brl-smoke.ARPA (Doug Gwyn ) (03/21/88)
In article <2424@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: >But BLISS is a machine-dependent language. I agree with most of your article, but BLISS isn't particularly machine-dependent. It is comparable to C in many ways. I have seen implementations for three substantially different architectures, and there may be more.
bzs@bu-cs.BU.EDU (Barry Shein) (03/22/88)
Re: What stops people from porting VMS to another machine? In the first place, let's distinguish between "port" (ie. moving a significant portion of the original source code) and "rewrite" (writing a program and/or OS on the new machine with the semantics of VMS.) People are confusing those two terms (perhaps the "rewrite" people are thinking "port" the semantics but not the code.) You can't port the code en masse (didn't they go out of business* :-) because it's not portable, a lot of it is Vax assembly code. In theory someone might be able to write a cross assembler or something which discompiles Vax assembly language to a higher level language but that's a fairly hard thing to do and the result is oftentimes unmaintainable. So, let's generally agree that you're not going to take the few hundred thousand lines of assembly code and non-portable Bliss code etc in VMS and just dump it on another machine and recompile it. Can you rewrite it? Maybe, it depends. You can almost certainly rewrite (and port, some of it will probably be reasonably portable) 90% or more of it. The problem is that the last few per cent may depend upon hardware features of the Vax (eg. the structure of the page translation hardware, security levels, interrupt structures etc) in ways that are critical to its performance. You could conceivably emulate these hardware elements with software in the kernel etc but this is a risky business and might impact performance or interfere with other parts of the system in an unacceptable manner. So chances are you'd have to compromise some of the semantics of the system, possibly important semantics (such as the entire presentation of the interrupt/signal structure to the application layers.) Would it still be VMS? Sure, as long as the lawyers register the name properly. Would it be desireable to people wanting VMS? Possibly, it would be quite a long bet as it could require many millions of dollars to accomplish only to find the result is not acceptable. A lot of that money could be saved, of course, by a careful analysis before setting out on the venture. DEC has, according to rumors, looked into this in different ways over the past few years. I know some of those attempts have turned up negative, it's conceivable they can take a different approach and succeed. No doubt the first thing they would have to do is define exactly what VMS is in a portable environment and whether or not a portable VMS will track the Vax version feature for feature, especially at every update release, etc. The upshot is, most anything is possible, whether it is potentially profitable or desireable is a different question. The other approach that seems to be DEC's is to try to extend the Vax hardware architecture into areas which the market seems to want, rather than porting VMS. For example, they've more or less extended it into the low end and another generation of that (eg. a $5K Vaxstation based on the new 3000 chip) might cover that well enough. Their real troubles seem to be in the high end right now, delivering anything close to what people want in mainframe performance (MIPs+IO, eg the IBM3090) and minisupercomputer performance (I don't think DEC should want to compete with Cray, but folks like Alliant and Convex in one spectrum and Encore and Sequent in another might be a reasonable goal, some of these folks have clear shots into the area of hundreds of MIPs for well under $1M, and others 100MFLOPs or more.) Right now they're attacking these domains with marketing hype (there was some system they had which claimed to rival the 3090, it had a dozen 8800s in the room or something like that, I don't think that's what users think of when they read "3090".) Eventually they're going to have consider providing an actual product which fits the bill. Again, there are rumors of real symmetrical multiprocessing using the Vax architecture, and possible new generations pushing it up into the speed range they will need to compete. This seems more plausible than porting VMS. Although a lot of these developments will no doubt make the Vax architecture more desireable in some arenas it still begs the question Unix answers, portability across distinct architectures which allows the rapid deployment of state of the art hardware into the marketplace which is critical to many fields to keep them competitive. At any rate, it should be interesting. -Barry Shein, Boston University * I better explain that before I get flamed, En Masse used to be a vendor.
bzs@bu-cs.BU.EDU (Barry Shein) (03/22/88)
Doug Gwyn responding to Rahul Desi >>But BLISS is a machine-dependent language. > >I agree with most of your article, but BLISS isn't particularly >machine-dependent. It is comparable to C in many ways. I have >seen implementations for three substantially different architectures, >and there may be more. I think the confusion here is that although Bliss is definitely a potentially machine independant language I doubt much VMS useage of Bliss is portable. It's much easier to work in all sorts of machine dependancies as you have to provide all sorts of user definitions for fundamental operations for each program you write, there are Bliss libraries but they tend to be weak on the portability issue. Also, there was never the tradition of portability in the Bliss community, programmers in practice seem to rarely consider it as a goal. I've programmed a fair amount in Bliss on a TOPS-20 system and was even thinking of portability but it was very hard to maintain (things like direct linkage to assembler routines to do system calls necessarily find their way into your code, almost unavoidably.) I would say the rewrite would approach a 50% re-effort even with the best of intentions, mostly because the non-portable pieces will also tend to be the most technically dense. So it remains more of a theory than practice, and I don't think Bliss will become the wave of the future (or was ever even the wave of the past, mostly due to DEC charging a huge amount of money for a Bliss compiler and the community that would use it not usually being in a position to buy such products.) It's too bad, it's an interesting language, albeit a bit dated. -Barry Shein, Boston University
stpeters@dawn.steinmetz (Dick St.Peters) (03/23/88)
In article <10745@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: >I would not be surprised to see a `VMS environment' in some future >Ultrix, however---not VMS itself but something that lets VMS folks >feel comfortable. Quite likely. As an alternate CLI (extra-cost option, of course), VMS now offers the "DEC shell" - essentially a Bourne shell, with cat, awk, sed, etc., enough to unpack many shar scripts if you strip off any "#! /bin/sh" line. DEC probably noticed the money that Interactive Systems and The Wollongong Group were making from products to make VMS look like UNIX. I believe I've seen an ad for a third-party UNIX emulation of VMS. -- Dick St.Peters GE Corporate R&D, Schenectady, NY stpeters@ge-crd.arpa uunet!steinmetz!stpeters
allbery@ncoast.UUCP (Brandon Allbery) (03/27/88)
As quoted from <2329@bath63.ux63.bath.ac.uk> by pes@ux63.bath.ac.uk (Smee): +--------------- | One of the more popular defenses of Unix is that 'well, it's easy to | provide user-friendly tailored environments'. I'd say that ideally you | shouldn't need to. (I think that the goal of Computer People should be | a system that *IS* friendly to everyone, rather than a system which can | be made to be friendly to everyone. Tricky? Sure. That's why we get | paid so well. A tailorable system -- like Unix -- is a good first | step, but it's ONLY a first step.) +--------------- To misquote Heinlein, "One man's user-friendly system is another man's belly laugh." Think about it. How can you be user-friendly to *everyone*? The beauty of Unix is that you can give user A a VMS-like environment and user B a pseudo-Macintosh, etc. Whereas Eunice is legendary and I doubt that VMS could support a Mac-ish front end. (I might be wrong on that last.) You are, however, correct on that first step. The question is, however, how should the front-ends be distributed? Should they come with Unix? Should they be add-on packages, perhaps by third parties (this is the way it is now)? Maybe some other way would be better? -- Brandon S. Allbery, moderator of comp.sources.misc {well!hoptoad,uunet!hnsurg3,cbosgd,sun!mandrill}!ncoast!allbery
miw@uqcspe.OZ (Mark Williams) (03/30/88)
In article <20788@bu-cs.BU.EDU> bzs@bu-cs.BU.EDU (Barry Shein) writes: >they're attacking these domains with marketing hype (there was some >system they had which claimed to rival the 3090, it had a dozen 8800s >in the room or something like that, I don't think that's what users >think of when they read "3090".) Eventually they're going to have >consider providing an actual product which fits the bill. > Oh, I don't know.... we have a 3081 here, and it looks *exactly* like half a dozen 8800s in a room. (and that doesn't include disk and tape drives) Actually, I think you mean the 8978, which is a cluster of 8 8700 processors claimed to push about 50 MIPS. Now this doesn't mean your FORTRAN program will run at 50 MIPS, but then an vector processor is only worthwhile for vectorised programs. Horses for Courses. Mark Williams -- DISCLAIMER: Whenever I tell them my opinions they fall asleep. It is better to have loved and lost, than to have spent your whole life winking