sbs@valid.UUCP (06/14/86)
I recently learned, via a Datamation article, that Honeywell is de-supporting Multics, and that Honeywell's customers are screaming and hollering. The reason this was interesting to me is that Multics, like UNIX(TM), is a ``cult'' operating system, by which I mean that it has a hard core of rabid, fanatical defenders. (Of course, none of us on the net is a drooling OS groupie; we all have sound technical reasons for preferring some systems to others.) For the last few years I've been a UNIX (ahem) user/fan/implementor, but recently my work -- I'm maintaining a schematics editor -- has led me into VMS. Now, to me, VMS is "just another vendor-supplied operating system." I don't like it as well as I like UNIX, but then again, I don't know it as well as I know UNIX, either. However, I've recently heard that there is a breed of VMS partisan every bit as intense as the most stalwart UNIX die-hard. So, finally to get round to the point, I have some questions: 1) For the VMS fans out there: what's your favorite feature(s) of the system? Why do you like it? How does it help you? 2) Likewise UNIX and Multics fans. (How do I get to a Multics site? I'm not on the MILnet...) 3) For anybody out there: what's your favorite system, or most fondly remembered, or the one you were most fanatical about? Why did you like it so much? Part of my reasons for posting are individual: I'm interested in learning more about VMS so that I can do my job better. But I'm also interested in the sociology of the thing, and if you are too, post or mail me. "After changes upon changes, we are more or less the same." -Paul Simon. S. (TM)UNIX is a trademark of AT&T Bell Laboratories. VMS is a trademark of the Digital Equipment Corporation.
larry@geowhiz.UUCP (Larry McVoy) (06/16/86)
In article <339@valid.UUCP> sbs@valid.UUCP (Steven Brian McKechnie Sargent) writes: > > 1) For the VMS fans out there: what's your favorite feature(s) of > the system? Why do you like it? How does it help you? I think that the main complaints with Unix from VMSites are 1) the BSD fortran compiler is the worst excuse for a compiler the world has ever seen (reports of 4 to 400 times slower than VMS fortran). 2) Related to (1), VMS fortran is a SUPERSET of ANSI Fortran 77 *and* is the defacto scientific standard. There are very few scientific research centers (remember science includes physics, math, chemistry; computer science is only questionably a science) that don't have Vaxen running VMS with the VMS fortran compiler. A great deal of established software depends on the extensions provided by DEC. 3) Likewise with DCL (Dec Command Language). It's like sh with more obscurity. *Large* DCL programs exist (my father who is a physicist has a modelling program with an enormous dcl frontend, like 10-15K lines. Unfortunately, stuff like this is not uncommon). This could be solved by writing a dcl-like shell. 4) EDT - the VMS screen editor. Somebody already fixed this by writing an emacs interface to emulate EDT. 5) Real time support. Other than Masscomp's RTU, VMS is the only company that I know of which supplies real time support. [From here on out they are my personal complaints; 1-5 were complaints that I have to listen to everytime I bump into a VMS person. They are as of yet blissflly ignorant of #6]. 6) File system. Why, oh, why, must the Unix file system be so fragile? VMS never loses your files. And it's faster to boot up. I have no idea what the difference is in design but somebody ought to have a look & see what could be done. 7) IPC. Shared memory, sockets, pty's, pipes, ioctls all over the place. And the only one that's not been hacked in as an after thought is pipes. IPC in Unix bytes the giant weenie. Talk to the guys at CMU, they've got all kinds of literature defending Mach based on this (and other design) problems. 8) Robustness. VMS almost *never* crashes. Unix crashes all the time. You damn near can't survive without source because you're always fixing something. DEC has never handed out VMS src. Unix is the ultimate example of "the quick fix solution"; those solutions always turn out to be wrong in the long run (trust me, this is the voice of experience talking. Sigh). 9) Related to (7), networking support. Sockets are gross. This isn't just my opinion, ask the DoD what they think of sockets. Remote filesystems, remote devices, etc, are all being kludged in by every OEM in the field. Have fun trying to make them all work together. Design? We don't need no stinkin' design, we got 10,000 lines of code. OK, now that I've got all the fanatics foaming at the mouth, let me throw in my disclaimer. I've been a Unix fanatic myself for the past 4 years. I'm just not blind to the problems that exist in Unix. As a research vehicle, as a development system, it's the nicest thing I've ever used. However, I have real problems recommending Unix as a "users" system. It needs a nursemaid to survive properly. Read net.mail - every time the postmaster at some large site leaves his job the mail gets all fouled up. What happened to programs that run themselves, without being nursed? Unix has too much folklore & guru-ness about it to be accepted into the mainstream. -- Larry McVoy ----------- Arpa: mcvoy@rsch.wisc.edu Uucp: {seismo, topaz, harvard, ihnp4}!uwvax!geowhiz!larry "Just remember, wherever you go -- there you are." -Buckaroo Banzai
mel1@houxa.UUCP (M.HAAS) (06/16/86)
VMS, Multics, MVS, CMS, Kronos, TOPS-10, Ibsys, etc. are all "just other vendor supported products". They all have been or will be "de-supported". It doesn't matter a bit what is good or better about any of them (unless, of course, there is a good idea or two there to incorporate into the portable operating systems - UNIX and PC-DOS). To have a favorite among these is to be stuck with just what the single vendor sells. Fine, if that suits your purposes now, but will it in the future? Is it worth your professional future to be expert in one of these albatrosses? They have a saying in real estate, "Value is measured by three factors: location, location, and location." A similar saying in computing is, "Value is measured by three factors: portability, portability, and portability." Mel Haas , odyssey!mel
tuba@ur-tut.UUCP (Jon Krueger) (06/17/86)
In article <339@valid.UUCP> sbs@valid.UUCP (Steven Brian McKechnie Sargent) writes: > 1) For the VMS fans out there: what's your favorite feature(s) of > the system? Why do you like it? How does it help you? My favorite VMS feature is its all-around functionality: you can put batch streams, high-end number crunching, transaction processing, real-time data acquisition and process control, document processing, graphics, simulation and number crunching, database management, casual use and computer education, highly interactive applications like spreadsheets and exploratory data analysis, software developement, expert systems, network interface, and so on through the entire gamut of applications ON A SINGLE MACHINE! With networking and clustering, you can put all of the above on a single, homogenous, manageable network or cluster. All your code will execute on any node. Needs for speed can be balenced against price of a given node. In other words, VAX is a good general-purpose computer, and VMS is a good general-purpose operating system. You can buy one box, support your applications and users under one environment, and stop there. The costs of fragmenting applications and user communities are just too high to justify any other way of doing business. The costs of maintaining a heterogeneous network are currently high, but may drop someday, which will change the picture. Other bright stars in VMS world: the debugger, sharable object and image libraries, the BACKUP, INSTALL, MONITOR, SYSGEN, ACCOUNTING, AUTHORIZE utilitiies for system management and tuning, the common calling standard (call a C run-time library routine and get printf from FORTRAN, COBOL, assembler, PASCAL, run a mixed FORTRAN-C or FORTRAN-COBOL shop), the transparency of file access in a DECnet. > 2) Likewise UNIX fans. My favorite Unix feature is vendor independence: getting cheaper, faster hardware to execute all my software. VMS cost DEC a lot, and DEC has to charge this back to its customers. Will Unix development and porting continue to add functionality to Unix faster and cheaper than DEC's hardware innovations can support cheaper copies of VMS? Probably. Right now, I see advantages to either system. Much of the chances for and rate of a swing to either system depends on the vendor. If DEC comes out with more VAX options, gets more competetive on hardware pricing, drops the BI bus fascism, and continues enhancing VMS, and ATT continues to give non-3B2 boxes second-class citizenship as Unix hosts, then Unix may end up being known as the first portable operating system, and of great historical and zero commercial significance. If ATT doesn't try to make us buy ATT hardware to get vmunix, but supports commodity hardware markets based on their licensed software, and DEC continues its BI bus childishness and hardware pricing, then VMS may end up as the last proprietary operating system, of interest only to a small and unhappy group of VAX owners.
chris@umcp-cs.UUCP (Chris Torek) (06/17/86)
[I deleted net.decus and net.usenix from the Newsgroups: header; both seem rather irrelevant here.] In article <452@geowhiz.UUCP>, larry@geowhiz.UUCP (Larry McVoy) writes: >I think that the main complaints with Unix from VMSites are > >1) the BSD fortran compiler is the worst excuse for a compiler the world has > ever seen (reports of 4 to 400 times slower than VMS fortran). `Fixed in 4.3'...? Well, not quite. Many of the performance problems and most (I may never again dare to say `all') of the bugs have been removed. For the hard-core VMS FORTRAN fan, there is the Ultrix port of VMS FORTRAN, about which I know nothing. In particular, many of the math library routines now use more of that beloved hand-tuned Vax assembly code. >5) Real time support. This is a valid criticism. To do VMS real-time code, one writes a driver and installs it with system privileges; the driver then has direct access to the hardware---or rather, that is my understanding of the process. It is a task of approximately the same complexity as writing and installing a Unix kernel driver, but one need not reboot, and driver bugs are less likely to cause catastrophe, as the VMS driver is somewhat insulated from the rest of the system. In other words, it is somewhat safer to trust anyone with random kernel-level hacking on VMS than it is on Unix. Somewhat. . . . >6) File system. Why, oh, why, must the Unix file system be so fragile? VMS > never loses your files. And it's faster to boot up. Except through my own stupidity or catastrophic hardware failure (head crashes and RA81 HDA glue problems), I have not lost a file for five years. Fragile? For that matter, most of our 785 boots take about six minutes: about three and a half for the console to load the WCS and the boot loader, and another two and a half before the terminals come awake and print `login: '. After a crash, a file system analysis and repair (as VMS puts it) takes perhaps an extra 25 minutes. (It used to be 15, until we turned an Eagle into an RA81 [the Eagle was needed by a Sun file server]). These crashes are usually due to power failures or other hardware problems. >7) IPC. This is indeed a serious problem, and one that I think (as does the CMU group, obviously) really requires a complete tear-out-the- guts-and-start-over approach. Along the way it will be helpful to simplify things, as is being done in Mach. >8) Robustness. VMS almost *never* crashes. Unix crashes all the time. It does? (I would run a `ruptime', but we had a power failure today that brought down everything in the building. Poor gyre also has an Emulex SC41/MS board with a bug that crashes it about every other day; I may kludge the driver to avoid it, if I can figure out how. It is somewhat difficult to write drivers without documentation.) (All right, 4.2BSD was quite buggy. I heard a rumour that there was a clause attached to the DoD funding that said that Berkeley had to ship 4.2 by some particular date. So, on that date, it was `grab a snapshot of whatever is there and ship': certainly not good practise, but money does help keep CSRGs going.) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1516) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu
chris@umcp-cs.UUCP (Chris Torek) (06/17/86)
In article <2041@umcp-cs.UUCP> I wrote: >Many of the performance problems [in f77] ... have been removed. >For the hard-core VMS FORTRAN fan, there is the Ultrix port of >VMS FORTRAN, about which I know nothing. In particular, many of >the math library routines now use more of that beloved hand-tuned >Vax assembly code. Oops. Invert the order of the last two lines. That flowing prose I produce >:-) is not done without some editing; and sometimes I miss a semantic glitch or two. (The `extra' `>' in the `smiley face' above represents deeley- boppers: an in joke for us USENIX groupies . . . .) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1516) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu
umdhep@eneevax.UUCP (Todd Aven) (06/17/86)
In article <339@valid.UUCP> sbs@valid.UUCP (Steven Brian McKechnie Sargent) writes: > > 1) For the VMS fans out there: what's your favorite feature(s) of > the system? Why do you like it? How does it help you? In article <452@geowhiz.UUCP> mcvoy@rsch.wisc.edu (Larry McVoy) writes: > I think that the main complaints with Unix from VMSites are > 3) Likewise with DCL (Dec Command Language). It's like sh with more obscurity. > *Large* DCL programs exist (my father who is a physicist has a modelling > program with an enormous dcl frontend, like 10-15K lines. Unfortunately, > stuff like this is not uncommon). This could be solved by writing a dcl-like > shell. DCL (which stands for Digital Command Language) is, like /bin/sh and variants, inappropriate for 10-15K programs. DCL, sh, csh, etc. are *interpreted* languages, and hence are REAL SLOW. The reason that command languages are used so widely is that one has no choice but to learn an operating system's command language, while on the other hand most people trying to do research hate like hell to learn a new programming language and will avoid it by writing 10-15K lines of command language 'script'. CLs are typically very forgiving of syntactical mistakes, too. I don't quite understand what problem is to be 'solved' by creating a DCL shell for UNIX, but I think that it would be neither interesting nor useful. On the other hand, a UNIX shell for VMS has been very helpful to me for those times that I just 'had to have a pipe' (:-). > 4) EDT - the VMS screen editor. Somebody already fixed this by writing an emacs > interface to emulate EDT. Why would anyone want the full-screen interface of EDT in GNU Emacs??? I admit that I use EDT, but ONLY in line mode for a quick one-line change. I'm trying to get SED to work so I never have to touch EDT! > [From here on out they are my personal complaints; 1-5 were complaints that I > have to listen to everytime I bump into a VMS person. They are as of yet > blissflly ignorant of #6]. My bliss is due to knowledge, not ignorance, of #6. > 6) File system. Why, oh, why, must the Unix file system be so fragile? VMS > never loses your files. BULLSH*T! I take great offense to that comment, having once spent an entire weekend trying to straighten out a royal mess. VMS allowed me to rename the root directory to be a sub-directory somewhere else. I was an idiot for doing it, but that proves that VMS is not idiot-proof. No OS is! > And it's faster to boot up. I have no idea what > the difference is in design but somebody ought to have a look & see what > could be done. By the time you added the UNIX equivalent to RMS (Record Management Services) onto your favorite brand of UNIX, you'd have crashes as the rule, not the exception. The difference in design is actually in the philosophy. VMS was not so much designed *for* the VAX as it was designed *with* the VAX. The basic VAX-11 processor was designed concurrently with it's operating system. My best guess is that UNIX was designed for the user, and the guru's have learned to tweak the source to the benefit of the machine. > 8) Robustness. VMS almost *never* crashes. Unix crashes all the time. You > damn near can't survive without source because you're always fixing > something. DEC has never handed out VMS src. Unix is the ultimate example > of "the quick fix solution"; those solutions always turn out to be wrong > in the long run (trust me, this is the voice of experience talking. Sigh). Come now, where are you getting your information? VMS crashes when people start poking into its guts as much as any other system (believe me!). You can survive without VMS source by groaning and moaning and waiting for the next release of VMS, which ain't so pleasant at times. But DEC absolutely ***DOES*** provide VMS source. It is distributed on microfiche under most licensing agreements, and for a price (a BIG PRICE) you can buy it in machine-readable form. As far as quick-fix solutions, I've written a few for VMS. I've even written some based on information provided in the fiche. > OK, now that I've got all the fanatics foaming at the mouth, let me throw in my > disclaimer. I've been a Unix fanatic myself for the past 4 years. I'm just > not blind to the problems that exist in Unix. As a research vehicle, as a > development system, it's the nicest thing I've ever used. However, I have > real problems recommending Unix as a "users" system. It needs a nursemaid > to survive properly. Read net.mail - every time the postmaster at some large > site leaves his job the mail gets all fouled up. What happened to programs > that run themselves, without being nursed? Unix has too much folklore & > guru-ness about it to be accepted into the mainstream. Just in case anybody has gotten confused about which side I'm really on, read on... VMS is the nicest operating system I've ever used (out of a sample of about 7, which isn't all that many). Period. I just wanted to clarify and correct the points made in the parent articles. Most of the complaints that I hear fro
paul@unisoft.UUCP (Paul Campbell) (06/17/86)
As an ex-VMS kernel hacker and now Unix kernel hacker I still have a healthy respect for VMS, it has many good features no Unix has how ever I have to disagree with Larry on some points. In article <452@geowhiz.UUCP> larry@geowhiz.UUCP (Larry McVoy) writes: > >6) File system. Why, oh, why, must the Unix file system be so fragile? VMS > never loses your files. And it's faster to boot up. I have no idea what > the difference is in design but somebody ought to have a look & see what > could be done. > It is in reality almost as fragile as most Unix systems .... its just that the system ALWAYS runs its own version of fsck when the system comes up after a crash. It too looses files, trashes them and puts them in a "lost+found" directory. VMS is more robust than Unix because it DOESNT have a block cache, it writes through directly to disk. All buffering is done at the record level. >8) Robustness. VMS almost *never* crashes. Unix crashes all the time. You > damn near can't survive without source because you're always fixing > something. DEC has never handed out VMS src. Unix is the ultimate example > of "the quick fix solution"; those solutions always turn out to be wrong > in the long run (trust me, this is the voice of experience talking. Sigh). > DEC will sell you source for about the same price as AT&T (commercial price that is). If you have support you get uptodate source listings on fiche ... beleive me after you have typed in all of the print symbiont (in assembler) paying for source seems like a much better idea ...... >9) Related to (7), networking support. Sockets are gross. This isn't just > my opinion, ask the DoD what they think of sockets. Remote filesystems, > remote devices, etc, are all being kludged in by every OEM in the field. > Have fun trying to make them all work together. Design? We don't need no > stinkin' design, we got 10,000 lines of code. > Here here, DECnet has a good user interface including particularly good support for user servers and protection, a (relatively slow) distributed file system comes with it. (I know I helped write a DECnet implementation ...) Let me add my own pluses for VMS +) It has a far better user memory management interface than Unix, many things you can do under VMS are IMPOSSIBLE under Unix, unless you get into the kernel of course +) Much of the kernel is paged And my one BIG minus about VMS -) Processes are far too expensive. Many things we take for granted under Unix are missing from or just too plain slow under VMS. The real problem is two-fold 1) VMS processes carry around too much context 2) The manner of creating a new process is such that transfering information from the old process is expensive. It happens automaticly in a Unix fork() On the whole I prefer Unix but I do find myself missing many features of VMS ... Thats all folks ...... Paul Campbell ..!ucbvax!unisoft!paul
thomas@utah-gr.UUCP (06/17/86)
In article <452@geowhiz.UUCP> larry@geowhiz.UUCP (Larry McVoy) writes: >1) the BSD fortran compiler is the worst excuse for a compiler the world has > ever seen (reports of 4 to 400 times slower than VMS fortran). Ultrix(tm) now comes with the "VMS" Fortran compiler (per report). > >3) Likewise with DCL (Dec Command Language). It's like sh with more obscurity. This is a plus?? >4) EDT - the VMS screen editor. Somebody already fixed this by writing an emacs > interface to emulate EDT. See (3). >6) File system. Why, oh, why, must the Unix file system be so fragile? VMS > never loses your files. I can count on the fingers of one foot the number of times I have lost a file due to "file system fragility" in the last 5 years on a Unix system. This "myth" is just that, and it's time to lay it to rest. >8) Robustness. VMS almost *never* crashes. Unix crashes all the time. See (6). Well, not quite that good. But the number of crashes not related to something like device driver development or installation of a half-baked remote file system has been VERY small at our site. I have seen a Vax stay up between PMs (every three months). Re: mail (one of your unnumbered comments). I think that a system that requires a remote machine to be up in order for you to send mail to someone on that system s**ks the big one. Maybe they've fixed it, but I doubt it. I remember watching a friend in France trying to send mail to Massachusetts, and having it fail because a connection couldn't be established to the remote machine *at that time*. No queueing, just try to send it later! Sheesh! Also, when was the last time you could run VMS on a Sun, or an Apollo, or a Gould, or a Pyramid, or a Cray, or .... 'Nuff said. -- =Spencer ({ihnp4,decvax}!utah-cs!thomas, thomas@utah-cs.ARPA)
jans@tekecs.UUCP (Jan Steinman) (06/18/86)
In article <1075@houxa.UUCP> mel1@houxa.UUCP (M.HAAS) writes: >VMS, Multics, MVS, CMS, Kronos, TOPS-10, Ibsys, etc. are all >"just other vendor supported products". They all have been >or will be "de-supported". It doesn't matter a bit what >is good or better about any of them (unless, of course, there >is a good idea or two there to incorporate into the portable >operating systems - UNIX and PC-DOS... > >"Value is measured by three factors: portability, portability, >and portability." Last I heard, PieceofCrap-DOS is portable only as long as Intel "supports" 80x86 processors, and as long as Microsoft sees money in it. This makes it "just (an)other vendor supported product" in my eyes! -- :::::: Artificial Intelligence Machines --- Smalltalk Project :::::: :::::: Jan Steinman Box 1000, MS 60-405 (w)503/685-2956 :::::: :::::: tektronix!tekecs!jans Wilsonville, OR 97070 (h)503/657-7703 ::::::
ken@njitcccc.UUCP (Kenneth Ng) (06/18/86)
In article <452@geowhiz.UUCP>, larry@geowhiz.UUCP (Larry McVoy) writes: > 3) Likewise with DCL (Dec Command Language). It's like sh with more obscurity. > *Large* DCL programs exist (my father who is a physicist has a modelling > program with an enormous dcl frontend, like 10-15K lines. Unfortunately, > stuff like this is not uncommon). This could be solved by writing a dcl-like > shell. If you don't mind other environment, I personally prefer IBM's REXX to DCL. REXX is a moderately structured interpreted lang which is the front end of a LOT of IBM applications. I've also seen it as the entire program in some cases. -- Kenneth Ng: uucp(unreliable) ihnp4!allegra!bellcore!njitcccc!ken soon uucp:ken@rigel.cccc.njit.edu bitnet(prefered) ken@njitcccc.bitnet soon bitnet: ken@orion.cccc.njit.edu (Yes, we are slowly moving to RFC 920, kicking and screaming) New Jersey Institute of Technology Computerized Conferencing and Communications Center Newark, New Jersey 07102 Vulcan jealousy: "I fail to see the logic in prefering Stonn over me" Movie "Short Circuit": Number 5: "I need input"
wje@lewey.UUCP (Bill Earl) (06/18/86)
>>I think that the main complaints with Unix from VMSites are >>6) File system. Why, oh, why, must the Unix file system be so fragile? VMS >> never loses your files. And it's faster to boot up. > Except through my own stupidity or catastrophic hardware failure > (head crashes and RA81 HDA glue problems), I have not lost a file > for five years. Fragile? For that matter, most of our 785 boots ... This has been my experience with 4.2 over the last two years as well (on a 4.2 with a number of the usual bug fixes). With an Emulex controller and three (full) Eagles, full system restart after a crash was only 15 or 20 minutes. A reboot which did not require file system checking (that is, after a clean shutdown) took only a minute or so. >>7) IPC. > This is indeed a serious problem ... I have occasion to use the IPC facilities quite a bit, and have found them reasonably convenient. 4.2 UNIX-domain sockets were very buggy, but internet sockets worked fine. Performance could be better, but it is at least tolerable at present. What is so bad about BSD sockets? >>8) Robustness. VMS almost *never* crashes. Unix crashes all the time. > It does? (I would run a `ruptime', but we had a power failure ... The (repaired) 4.2 system mentioned above often was up for two months or more at a time, and then was often shut down intentionally, not crashed. The largest single cause of crashes was power failure, followed by problems with a CDC disk which we eventually scrapped. Most of the (few) software crashes were due to UNIX domain sockets. This system was fairly heavily used, with a load average of 6 to 10 for 12 to 16 hours a day. At my current location, I have seen VMS (on a MicroVAX II) crash more than once. Our Ultrix V1.2 system has been quite stable, with no software crashes. I have also had occasion to work on Tandem systems, however. For reliability, neither UNIX nor VMS compare at all. I never lost a file in four years, and, on systems running released software, crashes were and are extremely rare, whether due to hardware or software. The only significant sources of failure were operator error (turning off all the disk drives or all the AC power) and AC power failure. Since disks were duplicated, drive failures were of little consequence. On the other hand, system restart was relatively slow (in the 15 minute range) and program development facilities fairly primitive, at least until recently. Nonetheless, as with Sequent and ELXSI systems, it is certainly nice to be able to spread a large number of compilations over 10 or 15 processors. William J. Earl American Information Technology, Cupertino, CA 408-252-8713 ...!decwrl!nsc!voder!lewey!wje -- William J. Earl American Information Technology, Cupertino, CA 408-252-8713 ...!decwrl!nsc!voder!lewey!wje
garry@batcomputer.TN.CORNELL.EDU (Garry Wiegand) (06/18/86)
I've been subjected to an unpleasantly large number of operating systems over the years (is WYLBUR still out there somewhere?), and I'm a VMS partisan. What comes to mind quickly: 1) Command names and switch names are reasonable, in English, and consistent across all the different programs. I don't have to carry a stupid encoding table around in my head. 2) The on-line Help is well-indexed, and it's HUGE. They've recently started digesting the language references into Help entries; I rarely need to page through a manual anymore. 3) The source-line debugger is exceedingly useful for program development and (after several years of hard work at DEC) I can say it works well. 4) The system services are logical, consistent, and well-documented. Anything a utility can do, a user program can do too. (And if you want to tickle the kernel, there *is* a thick manual on the system internals.) 5) VMS, she doesn't die, she doesn't break, she doesn't lose files, she just keeps running along. It's pretty trustworthy. I like MacIntoshes too, but that operating system is still in its infancy - "Inside the Mac" is not recommended light reading. PS - I don't buy the argument about "portable systems"! This industry is much too young to constrain itself to just one way of doing things. In the graphics system I designed last winter, I stole good ideas wherever I found them. From VMS, Unix, the Mac, even one from IBM! Not to mention all the "graphics packages" that had gone before. In diversity there is much richness. -- garry wiegand (garry%cadif-oak@cu-arpa.cs.cornell.edu)
harry@uw-atm.UUCP (Harry Edmon) (06/18/86)
My favorite operating system is Primos, especially rev 19.4 and later,
which allow dynamic linking to libraries, and user specified search rules
for the libraries. It is also easy to add your own command processor.
I just wish they would implement some Unix features in Primos (like uucp).
Primix (Prime's attempt at Unix :-(, is too crippled at the current release.
--
Harry Edmon uw-beaver!geops!uw-atm!harry
(206) 543-0547
Department of Atmospheric Sciences
University of Washingtonseifert@hammer.UUCP (Snoopy) (06/18/86)
In article <452@geowhiz.UUCP> larry@geowhiz.UUCP (Larry McVoy) writes: >8) Robustness. VMS almost *never* crashes. Unix crashes all the time. Doghouse has not crashed due to software for over a year, and that was when I was evaluating a new kernel and found a problem. (Which the kernel group fixed before I signed the paperwork to ship the release.) Hardware crashes are another story. I don't have a UPS, and it's hardly Unix's fault that someone plugs too much stuff in and throws the circuit breaker. I haven't lost any files, at any rate. (And yes, fsck runs automatically when the machine comes up, unless it was run as part of a clean powerdown.) If your machines are crashing "all the time", something is wrong, but don't blame it on "Unix". Snoopy tektronix!tekecs!doghouse.TEK!snoopy
gelfand@valid.UUCP (Brooks Gelfand) (06/19/86)
> VMS, Multics, MVS, CMS, Kronos, TOPS-10, Ibsys, etc. are all > "just other vendor supported products". They all have been > or will be "de-supported". It doesn't matter a bit what > is good or better about any of them (unless, of course, there > is a good idea or two there to incorporate into the portable > operating systems - UNIX and PC-DOS). To have a favorite > among these is to be stuck with just what the single vendor > sells. Fine, if that suits your purposes now, but will it > in the future? Is it worth your professional future to be > expert in one of these albatrosses? > > They have a saying in real estate, "Value is measured by three > factors: location, location, and location." A similar saying > in computing is, "Value is measured by three factors: portability, > portability, and portability." > Mel Haas , odyssey!mel This doesn't hold for the I.B.M. operating systems. While other manufactures fit the operating system to the hardware, since the introduction of the 360 I.B.M. has fitted the hardware to the operating systems and the application programs. Thus the operating system and computer evolve together. By placing microcode between the user and the hardware the user of the latest 3090 still "sees" a 360. In other words a program that was written and compiled on an old 360 will run on 3090. Is this "good"? If you are running a large data processing center with many millions of lines of source code, you don't want to have to recompile it just to upgrade machines. There is a price paid in raw speed. Perhaps your saying should be compatibility, compatibility, compatibality. Brooks Gelfand
fetrow@entropy.UUCP (David Fetrow) (06/19/86)
...and what about other Primos niceties:
As in UNIX much of the operating system is in high level language(s). The
older versions were relatively compact and written in FORTRAN IV...this may
no longer be considered all that wonderful but it sure made it easy for a
numbercruncher to make changes (like putting in real passwords).
PRIMOS 16 was one of the nicest first software playthings a person could ask
for. Warning: I use Unix, VMS, MS-DOS, TOPS-10 and CMS every day which makes
me something of a dillettante. The only systems I've played with the guts of
are Primos 16, MS-DOS and UNIX 4.X and never at the kernel level.
--
- Dave Fetrow
"Don't ask me how it works or I'll start to whimper" - Arthur Dent
"CP/M is nice because it has no more than 64K*8 errors per tick."
-Dave Fetrow
{ihnp4,tektronix}!uw-beaver!entropy!fetrow :UUCP
entropy!fetrow@uw-beaver.arpa :ARPA
fetrow@UWALOCKE,7833117@UWAVM :BITNET
74175,1724 :Compuservelibes@nbs-amrf.UUCP (Don Libes) (06/19/86)
In article <339@valid.UUCP> sbs@valid.UUCP (Steven Brian McKechnie Sargent) writes: > 1) For the VMS fans out there: what's your favorite feature(s) of > the system? Why do you like it? How does it help you? My favorite application under VMS on our 785 is Eunice. Don Libes {seismo,umcp-cs}!nbs-amrf!libes
geoff@desint.UUCP (Geoff Kuenning) (06/19/86)
In article <2041@umcp-cs.UUCP> chris@umcp-cs.UUCP (Chris Torek) writes: > >5) Real time support. > > This is a valid criticism. To do VMS real-time code, one writes > a driver and installs it with system privileges; the driver then > has direct access to the hardware---or rather, that is my understanding > of the process. Unfortunately for Unix, there is a lot more to doing a real-time application than simply writing funny device drivers. In fact, *lots* of DEC customers do major real-time control (e.g., entire factories) with DEC-standard hardware and drivers. You can buy A/D, D/A, and digital I/O interfaces from DEC, together with drivers and ISA standard Fortran libraries. Want to move a valve to a particular position? Call ADOUT with the appropriate parameters. And so forth. Furthermore, VMS has a plethora of system services that are absolutely necessary for general-purpose real-time applications. For example, there are many ways to handle asynchronous I/O and interprocess synchronization/communication (at least System V finally caught up with this last one). Again, these are readily available via ISA-standard libraries. Finally, VMS has numerous scheduler features (e.g., fixable priorities, notification of I/O completion) that are useful to real-time programmers. None of these are in Unix, and most are fairly difficult to add. This is not to imply I'm a VMS fan. I detest VMS as a user's and as a programmer's system. But it *does* have facilities that are just plain missing from Unix, and a lot of them are necessary for real-time applications. Finally, somebody else made the statement that DEC and Masscomp are the only manufacturers who have real-time operating systems. Nothing could be further from the truth. In the micro world, you have MTOS, VRTX, iRMX, something from Motorola (I forget the name), Charles River's UNOS, Wicat's MCS (at least it's advertised as real-time), the Masscomp offering, and several others. In minis essentially everybody has a real-time offering: DEC, DG, Prime, Tandem, HP (they now claim to have a real-time Unix). There are even real-time systems for mainframes (SABRE, the airline-reservations system, jumps to mind; the military does real-time on Crays). There are many, many more that I have left off the list simply because I'm doing it off the top of my head. But I think I've made my point. -- Geoff Kuenning {hplabs,ihnp4}!trwrb!desint!geoff
hsu@eneevax.UUCP (Dave Hsu) (06/19/86)
In article <486@batcomputer.TN.CORNELL.EDU> garry writes: >I've been subjected to an unpleasantly large number of operating systems >over the years (is WYLBUR still out there somewhere?), and I'm a VMS > >-- >garry wiegand (garry%cadif-oak@cu-arpa.cs.cornell.edu) WYLBUR is alive and well at various government institutions. Aside from Montgomery County Community College, is MUSIC still out there anywhere? -dave -- David Hsu (301) 454-1433 || -8798 "It was Dave, not me..honest!" -eneevax Communication & Signal Processing Lab / Engineering Computer Facility The University of Maryland -~- College Park, MD 20742 ARPA:hsu@eneevax.umd.edu UUCP:[seismo,allegra,rlgvax]!umcp-cs!eneevax!hsu "Unlike me, many of you have accepted your situation and will die here like rotten cabbages..." -Number 6
rick@nyit.UUCP (Rick Ace) (06/19/86)
> >6) File system. Why, oh, why, must the Unix file system be so fragile? VMS > > never loses your files. > I can count on the fingers of one foot the number of times I have lost a > file due to "file system fragility" in the last 5 years on a Unix > system. This "myth" is just that, and it's time to lay it to rest. > > ... > > =Spencer ({ihnp4,decvax}!utah-cs!thomas, thomas@utah-cs.ARPA) Well, almost a myth. UNIX filesystem implementations (even the touted one in 4.2bsd) trade off filesystem integrity for speed in places where other operating systems give you the guarantee that your data is safe. For example, when you issue the CLOSF JSYS to close a file in TOPS-20, you are assured that your data is safely out on the disk when the JSYS returns. The close(2) syscall, however, does *not* give you that guarantee, and I have gotten screwed at least once like this: Edit a file with my text editor Write the file out and exit editor Power failure (or other abrupt termination of UNIX) before next sync Reboot, fsck finds my file and claims it has no data blocks (the data was floating in the buffer cache when UNIX went down) Even more infuriating: neither the pre-edit nor the post-edit copy of the file remained after the crash, because the creat() syscall issued by the editor when writing out the file truncated the inode! I have since enhanced that editor to fsync() the file before close()ing it, but many people would argue that the operating system should take more responsibility for ensuring the safety of users' files. And what does one do on a UNIX variant without fsync()? The sync() syscall isn't really acceptable because 1) there is no way to limit the overhead to just one specific file, and 2) the return of sync() to the user program means only that the flush-to-disk operation has begun (i.e., you can't determine when it has completed). ----- Rick Ace Computer Graphics Laboratory New York Institute of Technology Old Westbury, NY 11568 (516) 686-7644 {decvax,seismo}!philabs!nyit!rick
guy@sun.UUCP (06/19/86)
A lot of the other complaints have already been shown not to be grounded in reality, so I won't bother adding more logs to the first.... > 7) IPC. Shared memory, sockets, pty's, pipes, ioctls all over the place. > And the only one that's not been hacked in as an after thought is pipes. Well, "hacked in as an afterthought" is a low-content (if not no-content) phrase; it could be interpreted as "anything not in First Edition UNIX was 'hacked in as an afterthought'", or "anything not put in at Research was 'hacked in as an afterthought'". Yes, there are problems with the various flavors of UNIX IPC, but they do get the job done; saying > IPC in Unix bytes the giant weenie. is somewhat extreme. > 9) Related to (7), networking support. Sockets are gross. This isn't just > my opinion, ask the DoD what they think of sockets. OK, how are sockets gross? How does the DOD think sockets are gross? Is it "sockets" they don't like, or perhaps the 4.2BSD TCP/IP implementation? Blaming sockets for the latter is like blaming C for the inadequacies of UNIX. > OK, now that I've got all the fanatics foaming at the mouth, let me throw > in my disclaimer. I've been a Unix fanatic myself for the past 4 years. It's interesting to note that another poster gave a long list of what they didn't like about VMS and liked about UNIX, and then said that VMS was their favorite system. > Read net.mail - every time the postmaster at some large site leaves his job > the mail gets all fouled up. What happened to programs that run themselves, > without being nursed? It's not clear this is UNIX's fault. There are programs which run under UNIX which "run themselves". There are programs (including, I suspect, some mail systems) running under other operating systems which don't. > Unix has too much folklore & guru-ness about it to be accepted into the > mainstream. I don't think this is intrinsic to UNIX. I suspect (especially given that a UNIX hacker gave a long list of what they saw as problems with UNIX, and that at least one VMS hacker gave a long list of what they saw as problems with VMS) that in many cases "favorite operating system" is equivalent to "first operating system that a person learned in depth", and that the question of which OSes are good and which are bad isn't very black-and-white. Much the same is true of editors, programming languages, etc.. -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com (or guy@sun.arpa)
ramin@rtgvax.UUCP (06/19/86)
In article <339@valid.UUCP>, sbs@valid.UUCP (Steven Brian McKechnie Sargent) writes: First of all, for certain applications, comparing un*x and vms would be like comparing a three-legged hemorrhoidal cat and the earwax inside Zaphod Beeblebrox's left ear(s) (go figure...) For real-time applications (I know, you've probably heard this one before), the standard (BSD 4.[23], S[V7etc...]) don't, how shall I say, "lend themselves" to real-time processing... Most notably, a decent paging mechanism, proper locks, a fine resolution clock, shared memory (or memory mapping to disk) and other distributed support are missing... (On the flip side, ultrix 1.2, which claims to be BSD4.3 plus SVID enhancements has the shared memory, and semaphore support, so things are looking up there). There is also a great deal of resistance to having to play with the kernel when adding support for some new type of peripheral... And many many more... On the other hand, VMS has some dandies too: Process creation is not unlike pulling a knee-cap out. Mailboxes are S-L-O-W, and mapping to disk-files by more than one process is not encouraged if both are writing... DECnet's user-level interface (as in DCL) is bogus as hell (YOU MEAN I HAVE TO TYPE MY PASSWORD ON THE SCREEN EVERYTIME I COPY FILES ACROSS? GO PROXY YOURSELF YOUNG MAN!!!). DCL is a joke of a shell (though it's getting better) with a funny idea for redirection... File naming syntax is VERY convoluted (there is actually a system call to VALIDATE the syntax of a filename!!!)... And many many more... Now that I'm done bitching about the two systems I must point that this type of questioning is rather misleading since preference for each system is basically a matter of use and a sprinkling of faith... If you like to see source code of the command you're using, don't look at vms (unless you have strong micro-fiche reading eyes). If you like your program to getup and run when you buy it, try vms (:-). Religiously, most will say that VMS is THE system for "serious" work, i.e. vs. play with source all day... If you're the end-user vms gives you more robust software, but less variety and definitely less support if things break. If you're the developer unix lets you do so many things faster and easier... So in conclusion.... I would buy a unix system with a vms cross-tool set. i.e. where I could develop on a unix, but the end result would run on vms...(:-) This is all too silly... I'm going out for a drink... ramin... > UNIX isn't but should be a trademark of D.M.Ritchie. > VMS should be the name of some type of plastic resin... -- =--------------------------------------=-------------------------------------= : alias: ramin firoozye' : USps: Systems Control Inc. : : uucp: ...!shasta \ : 1801 Page Mill Road : : ...!lll-lcc \ : Palo Alto, CA 94303 : : ...!ihnp4 \...!ramin@rtgvax : ^G: (415) 494-1165 x-1777 : =--------------------------------------=-------------------------------------= "Your wife is a genius. It's hard getting used to my furniture moving around."
stevem@fai.UUCP (06/20/86)
In article <452@geowhiz.UUCP> larry@geowhiz.UUCP (Larry McVoy) writes: >In article <339@valid.UUCP> sbs@valid.UUCP (Steven Brian McKechnie Sargent) writes: >> >> 1) For the VMS fans out there: what's your favorite feature(s) of >> the system? Why do you like it? How does it help you? > >I think that the main complaints with Unix from VMSites are > >1) ... >9) I thought it was an excellent list Larry, with one omission (the problem I'm grappling with now). DEC has over the years developed an excellent layered system of hardware and software that allows the addition of more machines without putting one bunch of users off by themselves on a separate machine. In fact to the users, Vax-clustering makes many machines look like one. There's no graceful way with UNIX to add a machine and not find that you have to segregate some users from others. -- -- Steven A. Minneman (Fujitsu America Inc, San Jose, Ca) !seismo!amdahl!fai!stevem or !ihnp4!pesnta!fai!stevem The best government is no government at all.
leo@sunybcs.UUCP (Leo Wilson) (06/20/86)
I really wanted to just spectate on this one...
The real problem with VMS is that it takes !screwdrivers and wrenches!
to install it. I don't even see it as really being a *software* product
(from a consumer's point of view) unless it is available for all my
current and future hardware.
VMS is really a GREAT os, with lots lots of plusses and only (count 'em)
ONE detractor: It's locked into a single vendor's hardware. (Oh, yeah,
expensive hardware, and pretty much state of two years ago's art, too.)
Oh, I have my druthers & UNIX answers lots more of them than VMS does,
but as far as I can see VMS has UNIX whipped all to hell in any work
environment other than ed or r&d. I have been looking, too. I'll
never actually USE it, tho, until I have the option to buy other companies'
*competitively* priced hardware.
How about it, DEC, turn VMS into purely a software product and "remember
UNIX" will become ONE word!
Trademarks: UNIX is a registered trademark of AT&T
VMS is a registered trademark of Digital Equiptment Corp.
DEC is probably a trademark of Digital Equiptment Corp.
(if i left anyone out, sue me & i'll move out of the
country before it gets to court.)larry@geowhiz.UUCP (Larry McVoy) (06/20/86)
In article <2121@hammer.UUCP> tekecs!doghouse.TEK!snoopy (Snoopy) writes: >In article <452@geowhiz.UUCP> larry@geowhiz.UUCP (Larry McVoy) writes: > >>8) Robustness. VMS almost *never* crashes. Unix crashes all the time. > >If your machines are crashing "all the time", something is wrong, >but don't blame it on "Unix". OK, OK, I'll bite on some of the replies I've received. 1) There are a large number of fanatics out there who foam at the mouth when ever someone bad mouths Unix. Tough life. I have no sympathy for such. 2) I was wrong about VMS src, I guess they do release it - on microfiche unless you want to pay mega$$ for machine readable. Sorry. 3) In regards to Unix robustness - I'll make you all a challenge: I'll bet I can take a commercially available Unix (BSD based, I don't play w/ AT&T & they don't play w/ me) and find twice as many ways to screw it up as you could in VMS. This means anything from kernel bugs to application bugs. The point is that Unix systems are hacked together things which work most of the time; you learn real fast which buttons not push. In VMS they took those buttons away. It's a much more solid product. 4) Crashing: You bet it crashes. Until you fix the bugs. Even the people who denied this said that if you added this or pushed that or diddled the other thing it would crash. Like I said, it crashes all the time. Look at the list of bugs *known* about BSD Unix. Look at tektronix, they claimed to have a port of 4.2 with over **2000** bug fixes. 2,000??? In a distribution version of Unix? Come on. At CS here it took them 6 months to a year to get 4.2 to the point that it didn't crash each time the load got to 20 on a 780 (I know, I used that vax during the "fixing" period). -- Larry McVoy ----------- Arpa: mcvoy@rsch.wisc.edu Uucp: {seismo, topaz, harvard, ihnp4}!uwvax!geowhiz!larry "Just remember, wherever you go -- there you are." -Buckaroo Banzai
mkr@mmm.UUCP (MKR) (06/20/86)
In article <339@valid.UUCP> sbs@valid.UUCP (Steven Brian McKechnie Sargent) writes: >I have some questions: > > 1) For the VMS fans out there: what's your favorite feature(s) of > the system? Why do you like it? How does it help you? > > 2) Likewise UNIX and Multics fans. (How do I get to a Multics > site? I'm not on the MILnet...) > I am somewhat enamoured of UNIX, although I currently use VMS for most of my work. I tend to dislike VMS as much as I like UNIX, but I didn't come here for a religious argument. (One jab - VMS users love to point out that VMS commands are English. That always struck me as meaningless when I can't remember *which* English word gets rid of a file - let's see... is it DELETE, REMOVE, PURGE, KILL, or what? How do I look at the contents... is it PRINT, TYPE, SHOW, LIST, DISPLAY, OUTPUT, CAT (heh heh) or what?) Anyway, what I wanted to point out was that if you want to learn all about UNIX, go to B. Dalton's or the equivalent. You can find row after row of books explaining UNIX, most of which do the job just fine. I wanted to learn more about VMS, and all I could find were the DEC manuals. Yechh! I find it hard to throw the 5 or 6 large binders I need into my briefcase to take them home for easy reading, even if the company would let me. And I'll be damned if I'm going to shell out a coupla grand to get my own copies. Nahhh - I'll take UNIX anyday. --MKR
loosemor@esunix.UUCP (Sandra Loosemore) (06/21/86)
I use both VMS and Un*x every day. I do nearly all my program development
under VMS, though, and I must admit that I like VMS a bit better. There
are a lot of operating systems that are a whole lot worse than Un*x though.
(Fortunately, I don't have to use those every day....)
I think the greatest advantage VMS offers over Un*x is the networked/shared
file system. VMS has had transparent network file access for at least 5
years, and this is just now working its way into Un*x. (They just installed
this as a "local hack" on the machines at the University of Utah -- it is
by no means a standard feature yet.) The VMS machines I use at work are
clustered, so the file structure looks exactly the same no matter which
machine I'm using. Given the current trend towards distributed computing
environments with personal workstations and compute servers, shared file
systems are very important things for an operating system to support.
Another thing I like about VMS is the documentation. There is a great deal
of tutorial information and examples in the manuals. It seems like when
I find I need to do something obscure with Un*x, I can never find the
right command to do it (or the documentation is so terse that I'm never
really sure whether it's the right command or not), and I end up having
to ask a "wizard". (Unix sites without "wizards" are really in trouble.)
I also wish Un*x had on-line help on how to use the shell, instead of
just the utilities!
I don't think that either VMS or Un*x has serious problems with file system
reliability; I've never lost a file under either OS. File versions under
VMS have saved me more times than I can remember, though. Again, this is
just another place where DEC has taken the trouble to try to "idiot-proof"
things, and we users appreciate it.
Of course, there are bad things about VMS too: as others have pointed out,
processes are incredibly slow to start up, the mailer is not too great (but
neither is the Un*x mailer, for that matter), all of the DEC editors are
pretty awful (but so is "vi"), etc. On the whole, though, Un*x is fine if
you want an "open" operating system where you can tweak everything in sight,
but if you just want to get a job done, VMS is a lot less hassle.
-Sandra Loosemore, Evans & Sutherland Computer Corp.
{decwrl, utah-gr!uplherc}!esunix!loosemor
loosemore@utah-20.arpa
[Insert usual disclaimers]wje@lewey.UUCP (06/21/86)
> ... DEC has over the years developed an excellent > layered system of hardware and software that allows the addition of more > machines without putting one bunch of users off by themselves on a separate > machine. In fact to the users, Vax-clustering makes many machines look like > one. There's no graceful way with UNIX to add a machine and not find that > you have to segregate some users from others. > > Steven A. Minneman (Fujitsu America Inc, San Jose, Ca) The above is not really true with respect to UNIX any longer. Several vendors offer working distributed file systems for UNIX. For example, NFS from SUN and TRFS from Integrated Solutions both allow easy expansion to new machines without segregating users. Also, Todd Brunhoff's RFS is included with 4.3 BSD, and has been distributed to the network. It works with both 4.2 BSD and 4.3 BSD. Even AT&T will eventually release their RFS for System V Release 3. UNIX today, especially BSD UNIX, is much more sophisticated in this area than it was a few years ago. William J. Earl American Information Technology, Cupertino, CA 408-252-8713 ...!decwrl!nsc!voder!lewey!wje -- William J. Earl American Information Technology, Cupertino, CA 408-252-8713 ...!decwrl!nsc!voder!lewey!wje
ccrdave@ucdavis.UUCP (Lord Kahless) (06/21/86)
> DECnet's user-level interface (as in DCL) is bogus as hell (YOU MEAN > I HAVE TO TYPE MY PASSWORD ON THE SCREEN EVERYTIME I COPY FILES ACROSS? > GO PROXY YOURSELF YOUNG MAN!!!). DCL is a joke of a shell It's trivial to write a DCL command procedure to read in the password for a DECNET copy without echoing it or retaining a history of it. Be fair. Learn what the system can and can't do before saying what it can't do.
levy@ttrdc.UUCP (Daniel R. Levy) (06/21/86)
In article <486@batcomputer.TN.CORNELL.EDU>, garry@batcomputer.TN.CORNELL.EDU (Garry Wiegand) writes: >I've been subjected to an unpleasantly large number of operating systems >over the years (is WYLBUR still out there somewhere?), and I'm a VMS >partisan. What comes to mind quickly: > >1) Command names and switch names are reasonable, in English, and consistent > across all the different programs. I don't have to carry a stupid encoding > table around in my head. Oh yes, and along with those verbose commands goes a command line which can't be over 255 characters long, and a library-archiver, compiler, and linker which can't take wild cards. Real nice when you have a 100-module program. Most Unix programs will print out a line or so of "usage" diagnostics if you invoke them with bogus arguments. Do VMS programs do this? > >2) The on-line Help is well-indexed, and it's HUGE. They've recently started > digesting the language references into Help entries; I rarely need > to page through a manual anymore. Tell me, is there one for the Fortran under VMS 4.x? On our 3.x VMS systems, we did indeed have a detailed online help for Fortran, and we have such a help now for C, but not for Fortran. Did someone just forget to install it, (system manager is baffled) or is it an "extra" (cost) item, or what? Unix online help need not be "HUGE" because the system interface isn't "HUGE." I think VMS is marvelous from many user points of view (despite my criticisms herein) but the system interface is a monstrous headache because of the complexity. > >3) The source-line debugger is exceedingly useful for program development and > (after several years of hard work at DEC) I can say it works well. That's nice, BUT what do you do when the program dies in an alpha-test environment? You get a nice stack-dump printout, but do you get a "core" which can be analyzed (especially if the sequence leading up the the crash is not easily reproducible?). (I _think_ there was supposed to be an option to RUN which would cause a program to produce the VMS equivalent of a core dump when it dies, but then can you pass parameters to the program, which as best as I understand cannot be done with RUN?) > >4) The system services are logical, consistent, and well-documented. Anything > a utility can do, a user program can do too. (And if you want to tickle the > kernel, there *is* a thick manual on the system internals.) Could you then do me a favor. Show me how, in Fortran, I would go about setting the protection (no fancy ACL stuff, just basic RWED protections) on a file which I am creating. (In C it's easy enough, since the protec- tion is specified when the file is created, which of course is tied to the straightforward Unix way of doing things!) Please show actual code, such as a USEROPEN program, together with the OPEN() statement that calls it, to run on VMS 4.2. Or even show me how I can do it in assembler. (I hesitate to say show me how to do it in the system programming language, since Bliss-32 is an "extra-cost" [and not really very commonly used outside of DEC, unlike C which is commonly used outside of Unix systems, let alone AT&T machines] option which I don't have. I think the analogy fair since that is what I would probably do if I needed to change the protection of a Unix file from Fortran [I would call chmod() in a C routine].) See also my comments under 2) about the system interface. It is massive, complex, and cumbersome, as well as introducing kludges into common pro- gramming languages, to be blunt. VMS does indeed pride itself on accessibility of system routines from "any" language, but this occurs at the cost of kludgey extensions (like Fortran STRUCTUREs and RECORDs and %val()s and %loc()s) to common programming languages, that a user would actually WANT to program in. C, which is a fairly common, "ordinary" programming language and sees wide use and portability even in non-Unix environments, fits the UNIX system interface very naturally and needs no such kludges to use it. (It is commendable that DEC has seen fit to switch rather than fight, and has provided an extensive UNIX-like interface to the VMS system within C.) > >5) VMS, she doesn't die, she doesn't break, she doesn't lose files, she > just keeps running along. It's pretty trustworthy. Oh yes, remember the security hole in VMS 4.1 about a nonprivileged user being able to crash the system by entering certain line-editing sequences in response to a prompt (involving ^B and some other escape codes). I succeeded in doing this once from DCL, and we have a plain VMS system, no special private kernel drivers installed. VMS 4.2 also kicked the bucket on me the other week when I was trying to access the help library. The system just barfed, and the console dump contained my process name. And I wasn't even trying any funny business or having any special privileges. Needless to say, Unix has never done this kind of thing. It is indeed possible for Unix files to get trashed if they have been "writ- ten" on (to the buffer cache) at a time which is less than the periodic system buffer flush period (typically 10-20 seconds) before a physical failure. It is however possible under SysV (and maybe BSD, but I'm not sure) to open() a file with an O_SYNC option, which will not return from the write() until the data has physically gone onto the storage medium. To do this is, unsurprisingly, much less efficient, but that, as with VMS RMS, is the price which is paid for security. Any user also can tell the system to flush the entire buffer cache with the sync() call, if they are worried about the integrity of what they have just written. > >I like MacIntoshes too, but that operating system is still in its infancy - >"Inside the Mac" is not recommended light reading. > >PS - I don't buy the argument about "portable systems"! This industry is much > too young to constrain itself to just one way of doing things. In the > graphics system I designed last winter, I stole good ideas wherever I > found them. From VMS, Unix, the Mac, even one from IBM! Not to mention > all the "graphics packages" that had gone before. > > In diversity there is much richness. If so, I am exceedingly glad that UNIX is part of that richness. (Diversity of hardware, too, spell that "vendor independence.") > > >-- >garry wiegand (garry%cadif-oak@cu-arpa.cs.cornell.edu) -- ------------------------------- Disclaimer: The views contained herein are | dan levy | yvel nad | my own and are not at all those of my em- | an engihacker @ | ployer or the administrator of any computer | at&t computer systems division | upon which I may hack. | skokie, illinois | -------------------------------- Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa, vax135}!ttrdc!levy
levy@ttrdc.UUCP (Daniel R. Levy) (06/21/86)
In article <486@batcomputer.TN.CORNELL.EDU>, garry@batcomputer.TN.CORNELL.EDU (Garry Wiegand) writes: >I've been subjected to an unpleasantly large number of operating systems >over the years (is WYLBUR still out there somewhere?), and I'm a VMS >partisan. What comes to mind quickly: > >1) Command names and switch names are reasonable, in English, and consistent > across all the different programs. I don't have to carry a stupid encoding > table around in my head. Oh yes, and along with those verbose commands goes a command line which can't be over 255 characters long, and a library-archiver, compiler, and linker which can't take wild cards. Real nice when you have a 100-module program. Most Unix programs will print out a line or so of "usage" diagnostics if you invoke them with bogus arguments. Do VMS programs do this? > >2) The on-line Help is well-indexed, and it's HUGE. They've recently started > digesting the language references into Help entries; I rarely need > to page through a manual anymore. Tell me, is there one for the Fortran under VMS 4.x? On our 3.x VMS systems, we did indeed have a detailed online help for Fortran, and we have such a help now for C, but not for Fortran. Did someone just forget to install it, (system manager is baffled) or is it an "extra" (cost) item, or what? Unix online help need not be "HUGE" because the system interface isn't "HUGE." I think VMS is marvelous from many user points of view (despite my criticisms herein) but the system interface is a monstrous headache because of the complexity. > >3) The source-line debugger is exceedingly useful for program development and > (after several years of hard work at DEC) I can say it works well. That's nice, BUT what do you do when the program dies in an alpha-test environment? You get a nice stack-dump printout, but do you get a "core" which can be analyzed (especially if the sequence leading up the the crash is not easily reproducible?). (I _think_ there was supposed to be an option to RUN which would cause a program to produce the VMS equivalent of a core dump when it dies, but then can you pass parameters to the program, which as best as I understand cannot be done with RUN?) > >4) The system services are logical, consistent, and well-documented. Anything > a utility can do, a user program can do too. (And if you want to tickle the > kernel, there *is* a thick manual on the system internals.) Could you then do me a favor. Show me how, in Fortran, I would go about setting the protection (no fancy ACL stuff, just basic RWED protections) on a file which I am creating. (In C it's easy enough, since the protec- tion is specified when the file is created, which of course is tied to the straightforward Unix way of doing things!) Please show actual code, such as a USEROPEN program, together with the OPEN() statement that calls it, to run on VMS 4.2. Or even show me how I can do it in assembler. (I hesitate to say show me how to do it in the system programming language, since Bliss-32 is an "extra-cost" [and not really very commonly used outside of DEC, unlike C which is commonly used outside of Unix systems, let alone AT&T machines] option which I don't have. I think the analogy fair since that is what I would probably do if I needed to change the protection of a Unix file from Fortran [I would call chmod() in a C routine].) See also my comments under 2) about the system interface. It is massive, complex, and cumbersome, as well as introducing kludges into common pro- gramming languages, to be blunt. VMS does indeed pride itself on accessibility of system routines from "any" language, but this occurs at the cost of kludgey extensions (like Fortran STRUCTUREs and RECORDs and %val()s and %loc()s) to common programming languages, that a user would actually WANT to program in. C, which is a fairly common, "ordinary" programming language and sees wide use and portability even in non-Unix environments, fits the UNIX system interface very naturally and needs no such kludges to use it. (It is commendable that DEC has seen fit to switch rather than fight, and has provided an extensive UNIX-like interface to the VMS system within C.) > >5) VMS, she doesn't die, she doesn't break, she doesn't lose files, she > just keeps running along. It's pretty trustworthy. Oh yes, remember the security hole in VMS 4.1 about a nonprivileged user being able to crash the system by entering certain line-editing sequences in response to a prompt (involving ^B and some other escape codes). I succeeded in doing this once from DCL, and we have a plain VMS system, no special private kernel drivers installed. VMS 4.2 also kicked the bucket on me the other week when I was trying to access the help library. The system just barfed, and the console dump contained my process name. And I wasn't even trying any funny business or having any special privileges. Needless to say, Unix has never done this kind of thing. It is indeed possible for Unix files to get trashed if they have been "writ- ten" on (to the buffer cache) at a time which is less than the periodic system buffer flush period (typically 10-20 seconds) before a physical failure. It is however possible under SysV (and maybe BSD, but I'm not sure) to open() a file with an O_SYNC option, which will not return from the write() until the data has physically gone onto the storage medium. To do this is, unsurprisingly, much less efficient, but that, as with VMS RMS, is the price which is paid for security. Any user also can tell the system to flush the entire buffer cache with the sync() call, if they are worried about the integrity of what they have just written. > >I like MacIntoshes too, but that operating system is still in its infancy - >"Inside the Mac" is not recommended light reading. > >PS - I don't buy the argument about "portable systems"! This industry is much > too young to constrain itself to just one way of doing things. In the > graphics system I designed last winter, I stole good ideas wherever I > found them. From VMS, Unix, the Mac, even one from IBM! Not to mention > all the "graphics packages" that had gone before. > > In diversity there is much richness. If so, I am exceedingly glad that UNIX is part of that richness. > > >-- >garry wiegand (garry%cadif-oak@cu-arpa.cs.cornell.edu) -- ------------------------------- Disclaimer: The views contained herein are | dan levy | yvel nad | my own and are not at all those of my em- | an engihacker @ | ployer or the administrator of any computer | at&t computer systems division | upon which I may hack. | skokie, illinois | -------------------------------- Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa, vax135}!ttrdc!levy -- ------------------------------- Disclaimer: The views contained herein are | dan levy | yvel nad | my own and are not at all those of my em- | an engihacker @ | ployer or the administrator of any computer | at&t computer systems division | upon which I may hack. | skokie, illinois | -------------------------------- Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa, vax135}!ttrdc!levy
bzs@bu-cs.UUCP (Barry Shein) (06/21/86)
Rather than hold this discussion about UNIX vs VMS now why not wait 2-3 years, when DEC starts giving their VMS to ULTRIX migration seminars at DECUS to encourage you to buy their new post-VAX processor... Oh no...DEC would *never* abandon all their TOPS um, er, I mean VMS customers... -Barry Shein, Boston University
johnth@batcomputer.UUCP (06/22/86)
In article <1000@ttrdc.UUCP> levy@ttrdc.UUCP (Daniel R. Levy) writes: >Could you then do me a favor. Show me how, in Fortran, I would go about >setting the protection (no fancy ACL stuff, just basic RWED protections) >on a file which I am creating. (In C it's easy enough, since the protec- >tion is specified when the file is created, which of course is tied to the >straightforward Unix way of doing things!) Please show actual code, such as >a USEROPEN program, together with the OPEN() statement that calls it, to run >.... The following is a trivial (and slow) way to do this. I'm sure there is a better way but sitting here this is the best I can do. OPEN() ... Close() Call Lib$Spawn('Set Protection=....') Personally I love to play with UNIX. It is a lot of fun to poke around in. On the other hand when I need to get things done I like VMS. It is easy because I don't need to think about how to do thinks, only about what I'm trying to get done. When I first started on VMS I just sat down at a terminal and started to see if I could make it go. My first command was EDIT TEST and it worked! Love at first sight. I would never have guessed vi. Now that I know a little about UNIX I like it. What I like about VMS is that I didn't need to take two weeks of workshops to learn enough to be able to use it. John Thurtell
syncro@looking.UUCP (Tom Haapanen) (06/22/86)
>> ... There's no graceful way with UNIX to add a machine and not find that >> you have to segregate some users from others. > The above is not really true with respect to UNIX any longer. >Several vendors offer working distributed file systems for UNIX. >For example, NFS from SUN and TRFS from Integrated Solutions both >allow easy expansion to new machines without segregating users. >Also, Todd Brunhoff's RFS is included with 4.3 BSD, and has been >distributed to the network. It works with both 4.2 BSD and 4.3 BSD. >Even AT&T will eventually release their RFS for System V Release 3. >UNIX today, especially BSD UNIX, is much more sophisticated in this >area than it was a few years ago. Supposedly SCO's just-announced XENIX-Net (developed with Microsoft who will sell it for the 68000 and other non-brain-damaged architectures) will provide transparent file sharing between a number of XENIX machines, using Sytek cards or something equivalent. Even just using Ethernet to hook up a bunch of VAXen without file sharing doesn't really amount to segregation. At University of Waterloo, we had over a dozen VAXen (plus uVAXen etc.) hooked together. You didn't feel segregated, because it was very easy to do things over the network: rcp (remote copy), rlogin, rsh, rwho and other commands make things easy. Mail would figure out what machine the recipient was on, and full-screen talk between machines made it really feel like just one big system. If I had to do some big makes or something, I'd find the machine with the smallest load, rcp the files over, do my work, and rcp the results back (no need to type in any passwords: your .rhosts file defined the authorized users). This was all running on all kinds of VAXen (uVAX, uVAX2, 750, 780, 785, 8600) using 4.2 BSD and Ultrix. -- \tom haapanen looking glass software ltd. syncro@looking.UUCP waterloo, ontario, canada watmath!looking!syncro (519) 884-7473 "These opinions are solely mine, although even I would like to deny them..."
bzs@bu-cs.UUCP (Barry Shein) (06/23/86)
From: larry@geowhiz.UUCP (Larry McVoy) >4) Crashing: You bet it crashes. Until you fix the bugs. Even the people who > denied this said that if you added this or pushed that or diddled the other > thing it would crash. Like I said, it crashes all the time. Look at the > list of bugs *known* about BSD Unix. Look at tektronix, they claimed to > have a port of 4.2 with over **2000** bug fixes. 2,000??? In a distribution > version of Unix? Come on. At CS here it took them 6 months to a year to > get 4.2 to the point that it didn't crash each time the load got to 20 on a > 780 (I know, I used that vax during the "fixing" period). This statement is full of misconceptions: 1. 2,000 bug fixes almost certainly includes the couple of hundred associated UNIX utilities, not kernel bugs. That's also probably over a period of what? 3 years? Given VMS and all of its utilities AND the layered products you have to add on from other vendors to even approach UNIX's function (eg. word processing, RUNOFF ain't troff, you better add ALL the bug fixes in the last 3 years to TeX or Scribe plus its printer drivers or whatever you added to your VMS system to do text processing, also DEC's CMS, Fortran, Bliss, some graphics packages, DecNot, etc etc etc) you'd probably have AT LEAST 2,000 bug fixes. Not to mention the constant hackery Sys Mgrs have to do with things like logical names for every new package added to a VMS system, they just can't see the whole system's design is a bug. Let's face it, UNIX out of the box is sufficient for many, many applications, VMS out of the box is a sensory-deprivation environment, if I remember right you don't get much more than an assembler, editor, debugger and the kernel itself (and a few unsupported things.) Besides, you make *no* attempt to indicate that there *weren't* 2,000 bug fixes in VMS since, oh, around when 3.0 was released, you just seem to assume this is true to prove your point, very weak. 2. It's clear you are comparing an original RESEARCH distribution of 4.2bsd with VMS. Get 4.2 these days from a serious vendor and see if your system crashes very often, it shouldn't. I seem to remember that the word on the street was that only a fool would run VMS4.0 before 4.1 came out because of the horrendous bugs, same basic thing except with UNIX you could probably fix a few bugs yourself and continue. Worse, without sources (see 3 below) your bugs had better be of interest to DEC or you'll get to sit on your hands while people have a ball cracking your system. Even when they're mildly interested it's rare to see a fix in less than months. 3. I've been over this availability of source for VMS before, check the Digital Reference Service under this product listing, you'll begin to doubt whether source is really available (is there a VMS SOURCE SITE anywhere out there?) First you'll notice your first $30K only buys kernel and a few things. The next $40K goes to Fortran, Decnet sources have no order number at all (or didn't last time I checked.) Then you notice this huge disclaimer that goes something like: Digital makes no guarantee that the sources provided will rebuild the system as distributed on the corresponding binary distribution. They further make no guarantee that you can even run the result of rebuilding their sources. In additon, only MAJOR RELEASES are available as source (eg. 4.0 but not 4.1, 4.2), if you wish the changes to be in your sources you can type them in yourself from the uFiche. Yeah, sounds like a good deal for $100K...(I also seem to remember they recommended strongly something like 1GB or more of free disk space to put the sources on and, being as it takes around 18 hours or more to re-build the kernel on a stand-alone 780 you had better throw a 780 CPU in with those disks, now add up the cost of sources.) I think this discussion borders on useless simply because it is clear the correspondants have almost exactly no real information and every intent to misrepresent what little they have. Have fun. By the time the correspondants settle down VMS will have gone the way of TOPS-20. Yes, I dislike VMS, but at least I bothered to sit down and read the DEC's product description before deciding whether sources were really available etc. -Barry Shein, Boston University
jimb@tekcbi.UUCP (06/23/86)
What about RSTS?????????? |-) |-) In particular, V9 (earlier versions don't count)
bzs@bu-cs.UUCP (Barry Shein) (06/24/86)
From: stevem@fai.UUCP (Steve Minneman) >...There's no graceful way with UNIX to add a machine and not find that >you have to segregate some users from others. Wrong. Try SUN's NFS. For the past 6 months the Computer Science Department's machine here (BU-CS) has been two SUN3/180s. It doesn't matter which one you log into as all disks are transparently visible. In fact, our terminal switch (U/B Net/1) randomizes which you land on and I have yet to hear a complaint. Being as SUN's NFS is starting to appear on many, many vendor's UNIX's this is not a narrow view of the world either (how many vendors are running VMS's clustering??) NFS also doesn't require a lot of fancy, expensive hardware of (given NFS) questionable value and it's bundled into the base price of the system. You just need an ethernet which you probably planned on having anyhow. -Barry Shein, Boston University
marco@andromeda.RUTGERS.EDU (the wharf rat) (06/24/86)
In article <77@rtgvax.UUCP>, ramin@rtgvax.UUCP (Pantagruel) writes: > when adding support for some new type of peripheral... And many many more... > > DECnet's user-level interface (as in DCL) is bogus as hell (YOU MEAN > I HAVE TO TYPE MY PASSWORD ON THE SCREEN EVERYTIME I COPY FILES ACROSS? > GO PROXY YOURSELF YOUNG MAN!!!). DCL is a joke of a shell (though it's > File naming syntax is VERY convoluted (there is actually a system call to > VALIDATE the syntax of a filename!!!)... And many many more... > How about " COPY FOO::DBA0:[FOOBAR]FOO.BAR BAR.FOO " ? No passwords.... And one good thing about checking file-names: You can't write files with control-chars in the names by mistake. W.rat
lcc.jbrown@locus.ucla.edu (Jordan Brown) (06/24/86)
> ... the portable > operating systems - UNIX and PC-DOS). PC-DOS? Portable? Don't make me laugh. It's portable to anything with an 8086 equivalent for a processor. And 2/3 or more of the applications can't survive unless they're running on an IBM PC (90% compatible and below need not apply). By this standard just about every OS I've seen is portable! (Hey, RT-11 runs on everything from an 11/03 to an 11/70, which is a much wider range of CPUs.) Yes, PC-DOS comes from somebody other than the hardware manufacturer (Intel). Great. Now you have to keep TWO companies alive to stay supported. Three if you count keeping IBM building PCs. The only reason that PC-DOS has done better than most other non-portable operating systems is IBM. Period.
rcb@rti-sel.UUCP (Random) (06/24/86)
I promised myself that I was going to stay out of this annual OS debate. However, I weakened. So here it comes. In article <1000@ttrdc.UUCP> levy@ttrdc.UUCP writes: >In article <486@batcomputer.TN.CORNELL.EDU>, garry@batcomputer.TN.CORNELL.EDU (Garry Wiegand) writes: >>1) Command names and switch names are reasonable, in English, and consistent >> across all the different programs. I don't have to carry a stupid encoding >> table around in my head. > >Oh yes, and along with those verbose commands goes a command line which can't >be over 255 characters long, and a library-archiver, compiler, and linker >which can't take wild cards. Real nice when you have a 100-module program. > The librarian and most compilers WILL take wildcards and have done so for some time. True the linker won't which is a bother. However, it would be nice if you check your arguments before posting them. >Most Unix programs will print out a line or so of "usage" diagnostics if you >invoke them with bogus arguments. Do VMS programs do this? > No. VMS programs will not let you invoke them with bogus arguments. Since the arguments are parsed by DCL before the program is invoked, if you give too many parameters or an unknown switch DCL will reject it with an error message that points out the specific problem. >> >>2) The on-line Help is well-indexed, and it's HUGE. They've recently started >> digesting the language references into Help entries; I rarely need >> to page through a manual anymore. > >Tell me, is there one for the Fortran under VMS 4.x? On our 3.x VMS systems, >we did indeed have a detailed online help for Fortran, and we have such a >help now for C, but not for Fortran. Did someone just forget to install it, >(system manager is baffled) or is it an "extra" (cost) item, or what? > This is the fault of your system manager for not reading the installation document that came with the fortran compiler. There are really 2 distributions on the tape. One for fortran and one for the help and the help is even more extensive than the one on 3.x. >Unix online help need not be "HUGE" because the system interface isn't "HUGE." >I think VMS is marvelous from many user points of view (despite my criticisms >herein) but the system interface is a monstrous headache because of the >complexity. > VMS online help is HUGE because it is complete. Unix help on the other hand... >> >>3) The source-line debugger is exceedingly useful for program development and >> (after several years of hard work at DEC) I can say it works well. > >That's nice, BUT what do you do when the program dies in an alpha-test >environment? You get a nice stack-dump printout, but do you get a "core" >which can be analyzed (especially if the sequence leading up the the crash >is not easily reproducible?). (I _think_ there was supposed to be an option >to RUN which would cause a program to produce the VMS equivalent of a core >dump when it dies, but then can you pass parameters to the program, which >as best as I understand cannot be done with RUN?) > A program can be linked to cause a "core" dump. Also, the core dump is analysed by the symbolic debugger. >> >>4) The system services are logical, consistent, and well-documented. Anything >> a utility can do, a user program can do too. (And if you want to tickle the >> kernel, there *is* a thick manual on the system internals.) > >Could you then do me a favor. Show me how, in Fortran, I would go about >setting the protection (no fancy ACL stuff, just basic RWED protections) >on a file which I am creating. (In C it's easy enough, since the protec- >tion is specified when the file is created, which of course is tied to the >straightforward Unix way of doing things!) Please show actual code, such as >a USEROPEN program, together with the OPEN() statement that calls it, to run >on VMS 4.2. Or even show me how I can do it in assembler. (I hesitate to >say show me how to do it in the system programming language, since Bliss-32 >is an "extra-cost" [and not really very commonly used outside of DEC, unlike >C which is commonly used outside of Unix systems, let alone AT&T machines] >option which I don't have. I think the analogy fair since that is what I >would probably do if I needed to change the protection of a Unix file from >Fortran [I would call chmod() in a C routine].) > Since I don't write in fortran, I can't give you the exact details, but the useropen routine should allocate a protection XAB and link it to the FAB passed into the useropen routine. When the open occurs, the protection will be right. >See also my comments under 2) about the system interface. It is massive, >complex, and cumbersome, as well as introducing kludges into common pro- >gramming languages, to be blunt. VMS does indeed pride itself on >accessibility of system routines from "any" language, but this occurs at >the cost of kludgey extensions (like Fortran STRUCTUREs and RECORDs and >%val()s and %loc()s) to common programming languages, that a user would >actually WANT to program in. C, which is a fairly common, "ordinary" >programming language and sees wide use and portability even in non-Unix >environments, fits the UNIX system interface very naturally and needs no >such kludges to use it. (It is commendable that DEC has seen fit to switch >rather than fight, and has provided an extensive UNIX-like interface to >the VMS system within C.) > Fortran structures, records, etc. do not exist for the purpose of kludgey interfaces to system routines. They exist to enhance fortran's capabilities. Structures and records provide better programming practices and %val and %loc allow rather sophisticated pointer operations to be done. >> >>5) VMS, she doesn't die, she doesn't break, she doesn't lose files, she >> just keeps running along. It's pretty trustworthy. > >Oh yes, remember the security hole in VMS 4.1 about a nonprivileged user >being able to crash the system by entering certain line-editing sequences >in response to a prompt (involving ^B and some other escape codes). I >succeeded in doing this once from DCL, and we have a plain VMS system, no >special private kernel drivers installed. VMS 4.2 also kicked the bucket >on me the other week when I was trying to access the help library. The >system just barfed, and the console dump contained my process name. And >I wasn't even trying any funny business or having any special privileges. >Needless to say, Unix has never done this kind of thing. > Would you mind also including the list of unix kernal bugs that can be activated by any user to kill the system. Assuming that there is disk space to keep the list. The above bug makes a good example for you to point to because it stands out. The reason it stands out is because it is the ONLY bug of it's kind I have ever seen since about version 2.5 >It is indeed possible for Unix files to get trashed if they have been "writ- >ten" on (to the buffer cache) at a time which is less than the periodic system >buffer flush period (typically 10-20 seconds) before a physical failure. It >is however possible under SysV (and maybe BSD, but I'm not sure) to >open() a file with an O_SYNC option, which will not return from the write() >until the data has physically gone onto the storage medium. To do this is, >unsurprisingly, much less efficient, but that, as with VMS RMS, is the price >which is paid for security. Any user also can tell the system to flush the >entire buffer cache with the sync() call, if they are worried about the >integrity of what they have just written. > Please let us not forget the great fun of trying to overwrite a file when the file system is full. The write fails as would be expected but has the nasty side effect of leaving a zero length file. Goodby data. >> >>I like MacIntoshes too, but that operating system is still in its infancy - >>"Inside the Mac" is not recommended light reading. >> >>PS - I don't buy the argument about "portable systems"! This industry is much >> too young to constrain itself to just one way of doing things. In the >> graphics system I designed last winter, I stole good ideas wherever I >> found them. From VMS, Unix, the Mac, even one from IBM! Not to mention >> all the "graphics packages" that had gone before. >> >> In diversity there is much richness. > >If so, I am exceedingly glad that UNIX is part of that richness. > >> >> >>-- >>garry wiegand (garry%cadif-oak@cu-arpa.cs.cornell.edu) >-- > ------------------------------- Disclaimer: The views contained herein are >| dan levy | yvel nad | my own and are not at all those of my em- >| an engihacker @ | ployer or the administrator of any computer >| at&t computer systems division | upon which I may hack. >| skokie, illinois | > -------------------------------- Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa, > vax135}!ttrdc!levy Before you get the idea that I am a rabid UNIX hater, I actually like some features of unix. I prefer VMS for it's consistancy, reliability and versatility. There are many unix emulators on VMS because it has the power and flexability to do a lot of different things easily. I have never seen a VMS emulator on unix however. And as for the good things about unix, I have ported or duplicated them on VMS so that I now have the best of both worlds. -- Random (Randy Buckland) Research Triangle Institute ...!mcnc!rti-sel!rcb
dml@rabbit1.UUCP (06/24/86)
> >> >6) File system. Why, oh, why, must the Unix file system be so fragile? VMS >> > never loses your files. >> I can count on the fingers of one foot the number of times I have lost a >> file due to "file system fragility" in the last 5 years on a Unix >> system. This "myth" is just that, and it's time to lay it to rest. >> >> ... >> >> =Spencer ({ihnp4,decvax}!utah-cs!thomas, thomas@utah-cs.ARPA) > > Well, almost a myth. UNIX filesystem implementations (even the touted > one in 4.2bsd) trade off filesystem integrity for speed in places > where other operating systems give you the guarantee that your data > is safe. For example, when you issue the CLOSF JSYS to close a file in > TOPS-20, you are assured that your data is safely out on the disk when > the JSYS returns. The close(2) syscall, however, does *not* give you that > guarantee, and I have gotten screwed at least once like this: > > Edit a file with my text editor > Write the file out and exit editor > Power failure (or other abrupt termination of UNIX) before next sync > Reboot, fsck finds my file and claims it has no data blocks > (the data was floating in the buffer cache when UNIX went down) > > Rick Ace Not only does UNIX have to have a sync to mark the file as ready for flush to the disk, some versions wait a further period of time to actually perform the flush to disK (i.e. sync does not do the flush itself - I know cause it happened to us). -- ----------------------------------------------------------- David Langdon Rabbit Software Corp. ...!ihnp4!{cbmvax,cuuxb}!hutch!dml ...!psuvax1!burdvax!hutch!dml (215) 647-0440 7 Great Valley Parkway East Malvern PA 19355
bzs@bu-cs.UUCP (Barry Shein) (06/24/86)
re: MKR mentions the problem of VMS manuals. At a DECUS a couple of years ago I was sitting and chatting with some of the DEC/VMS crew, some of them were involved in ULTRIX also. The issue of VMS in an academic environment came up. I was trying to not go into any flamage but it occurred to me that while the UNIX (4.2) manual set was available at our copy center for around $100 (and that includes broken out portions of the administrator's stuff etc, a realistic complete set for a student costs more like $50) an equivalent set of docs for VMS would fill a couple of bookshelves and cost hundreds of dollars. I basically said that it was a real problem, at our VMS site almost none of our -faculty- have sufficient VMS manuals in their office while at our UNIX sites I never see this problem, they'll just go to the copy center and buy what they need. I felt that this was a serious problem, that providing the real documentation (not to mention all the other publications useful for learning UNIX) was critical for a student environment to give them a sense of what the system was really about and to learn how to use documentation independantly. Their reaction was basically: "You know what, you're absolutely right, that *is* a serious problem now that you mention it." I only say this before the defenders of the one true faith go off babbling about manuals, sometimes something important is just overlooked and I think this is a case. Not sure what could be done, especially within the huge bureacracy that surrounds VMS, I know they have made some serious improvements in this since (those small binders) but I don't think it quite solves it (I'd love to think it had something to do with that conversation, not likely.) Not that I'd recommend VMS for educational use anyhow (for other reasons) tho I wouldn't condemn it either, just wouldn't be my choice (I mean, after all, if they used VMS how would they ever learn UNIX?! :-) -Barry Shein, Boston University
jordan@nike.UUCP (Jordan Hayes) (06/25/86)
Barry Shein <bzs@bu-cs.UUCP> writes:
it occurred to me that while the UNIX (4.2) manual set was
available at our copy center for around $100 (and that includes
broken out portions of the administrator's stuff etc, a
realistic complete set for a student costs more like $50) an
equivalent set of docs for VMS would fill a couple of
bookshelves and cost hundreds of dollars.
So true! By the way, the 4.3 manuals have been completely re-typeset
and look terrific -- in addition, they have been re-arranged, along the
lines of the 4.2 USENIX versions (although there are now 6 volumes
instead of the 5) ... no word yet about the availabilty of 4.3 manuals
from USENIX in the small format ...
Jordan Hayes
{ucbvax,decvax}!usenix!jordangrr@cbmvax.UUCP (06/25/86)
In article <802@tekcbi.UUCP> jimb@tekcbi.UUCP (Jim Boland) writes: > >What about RSTS?????????? |-) |-) >In particular, V9 (earlier versions don't count) RSTS is an absoulutly great system for what it was originally intended for - a general purpose / educational timesharing system with user- accessable software written in BASIC. Along the way, it has learned to do many more things, some of which are really better done on other systems. If you think it is clunkey, then you should consider the competition around 1971 - you could spend $$$ and get a Burroughs B5500 or PDP-10, or get a mini-computer and not be able to do much, although TSS-8 wasn't too bad. /- VMS ---------> RSX-11 ---------------------------> OS/8 -> DOS...BATCH -> RT11 ----------------> TOPS-10 ------------------------ TOPS-20 ----------------> \- TSS-8 -> RSTS --------------------------------> Unix ------------------------------> ** funny how most of them are still around, huh? ** Well, maybe RSTS V2A20 did have a bug or two, but it was fun... -- George Robbins - now working with, uucp: {ihnp4|seismo|caip}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@seismo.css.GOV Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
henry@utzoo.UUCP (Henry Spencer) (06/26/86)
> 3) In regards to Unix robustness - I'll make you all a challenge: I'll bet I can > take a commercially available Unix (BSD based, I don't play w/ AT&T & they > don't play w/ me) and find twice as many ways to screw it up as you could > in VMS. This means anything from kernel bugs to application bugs. Since you have carefully excluded the AT&T Unixes, which are rather better debugged, you've rigged the comparison. It's no secret that 4BSD is riddled with bugs -- what else do you expect, given its origin? A university is not a software house, even if a DoD contract claims that it's supposed to act like one. If you doubt this, point to the quality-control people at UCB. > ... Look at tektronix, they claimed to > have a port of 4.2 with over **2000** bug fixes. 2,000??? In a distribution > version of Unix? Come on... What's odd about this? OS/360 averaged 1000 bugs/release for a long time. That's *unfixed* bugs, mind you. -- Usenet(n): AT&T scheme to earn revenue from otherwise-unused Henry Spencer @ U of Toronto Zoology late-night phone capacity. {allegra,ihnp4,decvax,pyramid}!utzoo!henry
hobbit@ecsvax.UUCP (Derrell Piper) (06/26/86)
VMS is a sensory deprivation experiment? Oh come on. (If I could only figure out what obscure command would append my address to this mail. Oh yeah, :r address.txt. Obviously. How do I send this mail? Not SEND, but "f-". Yeah, right. Derrell Piper 120 Rosenau Hall (201H) School of Public Health University of North Carolina - Chapel Hill Chapel Hill, NC 27514 (919) 966-5106 Bitnet: derrell@uncsphvx.BITNET Usenet: ...decvax!mcnc!ecsvax!hobbit
aglew@ccvaxa.UUCP (06/26/86)
>WYLBUR is alive and well at various government institutions. >Aside from Montgomery County Community College, is MUSIC still out >there anywhere? By MUSIC, do you mean the infamous McGill University System for Interactive Computing? Running on IBMs? If so, yeah, it's still out there, except now it's an official IBM product, with the university name taken out of it. The amazing thing about MUSIC is that the guys who wrote it say they based a lot of its design upon UNIX - and I almost believe them. Everything except the user interface. Andy "Krazy" Glew. Gould CSD-Urbana. USEnet: ihnp4!uiucdcs!ccvaxa!aglew 1101 E. University, Urbana, IL 61801 ARPAnet: aglew@gswd-vms
rcb@rti-sel.UUCP (Random) (06/26/86)
In article <841@bu-cs.UUCP> bzs@bu-cs.UUCP (Barry Shein) writes: > >re: MKR mentions the problem of VMS manuals. > >At a DECUS a couple of years ago I was sitting and chatting with some >of the DEC/VMS crew, some of them were involved in ULTRIX also. The >issue of VMS in an academic environment came up. I was trying to not >go into any flamage but it occurred to me that while the UNIX (4.2) >manual set was available at our copy center for around $100 (and that >includes broken out portions of the administrator's stuff etc, a realistic >complete set for a student costs more like $50) an equivalent set of >docs for VMS would fill a couple of bookshelves and cost hundreds of >dollars. I basically said that it was a real problem, at our VMS site >almost none of our -faculty- have sufficient VMS manuals in their office >while at our UNIX sites I never see this problem, they'll just go to the >copy center and buy what they need. > There is now available for microVMS and I think for VMS4.4 a 2 manual set that is a basic reference of the most needed items. It also takes up exactly as much shelf space as the 5 manual unix set. Maybe they listened to you? >... (I mean, after all, if they used VMS how would they ever learn UNIX?! :-) > > -Barry Shein, Boston University That should read: (I mean, after all, if they used VMS why would they ever WANT to learn UNIX :-) -- Random (Randy Buckland) Research Triangle Institute ...!mcnc!rti-sel!rcb
tihor@acf4.UUCP (Stephen Tihor) (06/28/86)
The last version of the Internal Manual for VMS cost $50.
garry@batcomputer.TN.CORNELL.EDU (Garry Wiegand) (06/30/86)
(cross-posted to info-vax) By just saying what I *liked* about VMS, and not saying *anything* about any other operating system, I was trying hard not to get drawn into the Unix wars. But I can't take the all the nonsense (tho there's been some sense too) that's been flowing by. Specifically: 1) Any message that begins with something of the form of "I prefer Unix but I'm a VMS expert too and I know you can't do ..." deserves an immediate 'n' key. The body of the message can be safely assumed to be wrong. 2) The C language and the C run-time library are no longer the same thing as "Unix"! I have cheerfully carried C programs full of library calls back and forth between my VMS Vax, my Unix Vax, a MS-DOS PC, and a MacIntosh. It's easy. When I want to create a file with a specific file protection (not that I ever have wanted such a thing :-)) I call 'creat'. Yes, on VMS! What we're supposed to be having here is a system war, not a language war. Let's keep it pure, people! 3) The c-shell and Bourne shell are fine and wonderful in and of themselves, and would be a nice amenity on any system. Wollongong's implementation of them on VMS side-stepped the process creation problem, but they unfortunately lost the DCL commands somewhere else along the way, leaving only the Unix syntax. I like my DCL command syntax and I'd love to be able to wrap a better control structure around them. (I haven't seen Dec/Shell yet; don't know if they did it right.) Anyhow, the *shell* isn't "Unix" either! 4) What *is* unique to a Unix system are the Unix system service calls, like 'stty' and 'fork' (as opposed to 'vfork'). This has made carrying system-referencing utilities between vanilla unixae pretty easy, and I can't deny it. But see diatribe. *Diatribe begins here* What I see now is Berkeley diverging from Bell Labs, all the micros out there diverging from both, and many wizards burning the midnight oil adding whizbangs like sockets, asynchronous I/O, window managers, semaphores and network file systems -- things that will never be propagated to the whole unix world. Soon you will have to refer to Unix as "a family of operating systems", seriously overlapping with other systems like VMS. Which is all to the good. "Cross-fertilization", says I. "Willingness to listen to other ideas", says I. When it comes to something as complex as an operating system and all its support utilities, don't close yourself out. Listen to the VMS hackers. Standards are for dead people. (Now, can I please have a good Ultrix debugger?) *end diatribe* -- garry wiegand (garry%cadif-oak@cu-arpa.cs.cornell.edu)
coleman@sask.UUCP (Geoff Coleman) (06/30/86)
> > Before you get the idea that I am a rabid UNIX hater, I actually like some > features of unix. I prefer VMS for it's consistancy, reliability and > versatility. There are many unix emulators on VMS because it has the power > and flexability to do a lot of different things easily. I have never seen > a VMS emulator on unix however. And as for the good things about unix, > I have ported or duplicated them on VMS so that I now have the best of both > worlds. > -- Why would anyone want to emulate VMS on a UNIX machine. Most people just leave good enough alone. By the way have you ever tried to link a VMS program which uses libraries with circular calls (ie. a routine in library A calls a routine in library B which calls a routine in library A). I tried linking a graphics program the other day with just such a setup and I ended up listing each library twice thus you get one very long command line. > Random (Randy Buckland) > Research Triangle Institute > ...!mcnc!rti-sel!rcb Geoff Coleman disclaimer: these are not opinions
rdz@cci632.UUCP (Robert D. Zarcone) (06/30/86)
In article <828@bu-cs.UUCP> bzs@bu-cs.UUCP (Barry Shein) writes: > >I think this discussion borders on useless simply because it is clear >the correspondants have almost exactly no real information and every >intent to misrepresent what little they have. Have fun. By the time >the correspondants settle down VMS will have gone the way of TOPS-20. > I MAY BE WRONG, but can you name me a MAJOR (Fortune 500) manufacturer besides AT&T that offers UNIX as their only operating system? If I am right, you will find they offer UNIX as an alternative OS. Your statement would have us believe that the world's second largest manufacturer of computers can't compete with just a proprietary OS. Would you also have us believe that IBM is doomed if they don't drop their proprietary OS's and convert to UNIX? If so, please contact me concerning this bridge in NYC I know about. :-)
arnold@ucsfcgl.UUCP (Ken Arnold%CGL) (07/02/86)
This discussion is not relevant to net.usenix. Please delete it from the list of newsgroups. net.usenix is for discussions about the USENIX association, not debates about UNIX. Ken Arnold
bzs@bu-cs.UUCP (Barry Shein) (07/03/86)
>>In article <828@bu-cs.UUCP> bzs@bu-cs.UUCP (Barry Shein) writes: >> >>I think this discussion borders on useless simply because it is clear >>the correspondants have almost exactly no real information and every >>intent to misrepresent what little they have. Have fun. By the time >>the correspondants settle down VMS will have gone the way of TOPS-20. >> >From: rdz@cci632.UUCP (Robert D. Zarcone) >I MAY BE WRONG, but can you name me a MAJOR (Fortune 500) manufacturer >besides AT&T that offers UNIX as their only operating system? If I am >right, you will find they offer UNIX as an alternative OS. Your statement >would have us believe that the world's second largest manufacturer of >computers can't compete with just a proprietary OS. Would you also have >us believe that IBM is doomed if they don't drop their proprietary OS's >and convert to UNIX? If so, please contact me concerning this bridge in >NYC I know about. :-) You're not utterly wrong, but picking some holes reveals some interesting things: 1. Sperry seems to be moving strongly towards only offering UNIX and dropping their other lines. It's hard to predict whether this will actually happen. I think they are 'major' in dollars. 2. I am not sure what the "MAJOR (Fortune 500)" is meant to prove. IBM is a $45 billion dollar company, ATT is about the same, DEC is a $7 billion dollar company (around 1/7th the size of either.) If I used your reasoning I would either be using IBM mainframe systems or UNIX (hey, ya know what, that's exactly what I do!) 3. DEC is no longer the 2nd largest manufacturer (and as I pointed out, they were a distant second), Burroughs-Sperry is, I think DEC was recently pegged as fourth (not sure who three is, if the WSJ meant Burroughs-Sperry as 2 and 3 then they're stupid, but at best DEC has fallen to number 3.) 4. I didn't say they can't compete, I meant they won't want to. They'll be too afraid of falling behind in the MIPs/$$ wars with the VAX architecture and, fanatics aside, I am very skeptical that they will ever port VMS to something other than a VAX. Exactly what made it their pride and joy (squeezing every cycle out of a VAX) will also be it's demise. Remember, if DEC is to survive they had better make these decisions BEFORE they start failing to compete or it will be too late. 5. At any rate (why did I start numbering these things?) to compare DEC to IBM is very questionable. DEC is in the market, IBM *is* the market. DEC has competitors, it's still not clear that IBM has any, maybe ATT someday (hell, maybe DEC **SOMEDAY**, not today, not in terms of sales.) Although DEC is number three (I don't care, number two, let's go back a few months) there are several companies well positioned to give them some stiff competition (Burroughs-Sperry, ATT, Honeywell, CDC, Data General, Prime, Harris, Wang [who I hear is going heavily UNIX], others, probably more in the near future [I'd put my money on SUN in 2-3 years.]) See, whereas none of these companies really competes with IBM they constantly go head-on with DEC, especially in large contract bids. Note also that both IBM and (to some extent) DEC got strongly behind their UNIX products when NSA chose ATT for a $1B procurement which required UNIX and TCP/IP (note that ATT rushed out a TCP/IP product also...) IBM dropped out early and DEC was just beat in the last heat. Now, ain't none of them gonna resist the Pentagon's desires (which NSA was reflecting in this contract.) You could draw an analogy with ADA and say we should therefore all use ADA, but I don't see that kind of $$ yet behind ADA, and besides, they'll use ADA on UNIX, it's not being promoted for general systems programming. No, IBM won't drop MVS in the near future, DEC will drop VMS (I predict 2-3 years, at least as a major product.) -Barry Shein, Boston University
levy@ttrda.UUCP (Daniel R. Levy) (07/05/86)
In article <873@rti-sel.UUCP>, rcb@rti-sel.UUCP (Random) writes: >I promised myself that I was going to stay out of this annual OS debate. >However, I weakened. So here it comes. >In article <1000@ttrdc.UUCP> levy@ttrdc.UUCP writes: >>Oh yes, and along with those verbose commands goes a command line which can't >>be over 255 characters long, and a library-archiver, compiler, and linker >>which can't take wild cards. Real nice when you have a 100-module program. >The librarian and most compilers WILL take wildcards and have done so for >some time. True the linker won't which is a bother. However, it would be nice >if you check your arguments before posting them. I owe the net an apology; I tried it again with the LIBRARY command and yes (whew), it does work. So it's easy to build libraries (and in all fairness too, the LIBRARY command is quicker than the UNIX 'ar' when inserting modules in the middle is involved). However, as Random admits, it won't work with the linker, and contrary to what he says, it won't work with "most compilers" (at least not "most compilers" that I have had opportunity to use!). e.g. (VMS 4.2): $ SET DEFAULT [LEVY.C] $ DIR Directory UD6:[LEVY.C] FILE1.C;1 FILE2.C;1 Total of 2 files. $ CC *.C %CC-F-OPENIN, error opening UD6:[LEVY.C]*.C; as input -RMS-F-WLD, invalid wildcard operation $ SET DEFAULT [LEVY.FORTRAN] $ DIR Directory UD6:[LEVY.FORTRAN] FILE1.FOR;1 FILE2.FOR;1 Total of 2 files. $ FORTRAN *.FOR %FORT-F-OPENIN, error opening UD6:[LEVY.FORTRAN]*.FOR; as input -RMS-F-WLD, invalid wildcard operation %FORT-F-ABORT, abort $ SET DEFAULT [LEVY.MACRO] $ DIR Directory UD6:[LEVY.MACRO] FILE1.MAR;1 FILE2.MAR;1 Total of 2 files. $ MACRO *.MAR %MACRO-E-OPENIN, error opening UD6:[LEVY.MACRO]*.MAR; as input -LIB-E-NOWILD, no wildcard permitted $ SET DEFAULT [LEVY.MODULA2] $ DIR Directory UD6:[LEVY.MODULA2] FILE1.MOD;1 FILE2.MOD;1 Total of 2 files. $ MODULA *.MOD %MODULA-F-IOERR, problem during Open operation for file UD6:[LEVY.MODULA2]*.MOD; -RMS-F-WLD, invalid wildcard operation $ LO LEVY logged out at 28-JUN-1986 20:21:04.43 (Me:) >>Most Unix programs will print out a line or so of "usage" diagnostics if you >>invoke them with bogus arguments. Do VMS programs do this? >> (Random:) > >No. VMS programs will not let you invoke them with bogus arguments. Since >the arguments are parsed by DCL before the program is invoked, if you give >too many parameters or an unknown switch DCL will reject it with an error >message that points out the specific problem. Ah now, if only DCL were smart enough to give a diagnostic which is a little more "specific" than this: $ SHOW USERS/BOGUS %DCL-W-IVQUAL, unrecognized qualifier - check validity, spelling, and placement \BOGUS\ I'd much prefer to see something like this, which is from SysV: $ who -BOGUS who: illegal option -- B Usage: who [-rbtpludAasHTq] [am i] [utmp_like_file] r run level b boot time t time changes p processes other than getty or users l login processes u useful information d dead processes A accounting information a all (rbtpludA options) s short form of who (no time since last output or pid) H print header T status of tty (+ writable, - not writable, x exclusive open, ? hung) q quick who > >>> >>>2) The on-line Help is well-indexed, and it's HUGE. They've recently started >>> digesting the language references into Help entries; I rarely need >>> to page through a manual anymore. >>Tell me, is there one for the Fortran under VMS 4.x? On our 3.x VMS systems, >>we did indeed have a detailed online help for Fortran, and we have such a >>help now for C, but not for Fortran. Did someone just forget to install it, >>(system manager is baffled) or is it an "extra" (cost) item, or what? >This is the fault of your system manager for not reading the installation >document that came with the fortran compiler. There are really 2 distributions >on the tape. One for fortran and one for the help and the help is even more >extensive than the one on 3.x. I owe somewhat of an apology for this flame, and will go beat on my system manager to install the fuller HELP :-). >>Unix online help need not be "HUGE" because the system interface isn't "HUGE." >>I think VMS is marvelous from many user points of view (despite my criticisms >>herein) but the system interface is a monstrous headache because of the >>complexity. > >VMS online help is HUGE because it is complete. Unix help on the other hand... Well, maybe I shouldn't say that UNIX help is so small. (WARNING: LOTS OF TEXT FOLLOWS!) $ ls -sRC /usr/catman total 3 1 a_man 1 p_man 1 u_man /usr/catman/a_man: total 7 4 man1 2 man7 1 man8 /usr/catman/a_man/man1: total 559 2 errstop.1m.z 3 qasurvey.1m.z 3 Uutry.1m.z 6 ff.1m.z 3 reboot.1m.z 2 abt.1m.z 2 filesave.1m.z 2 rmv.1m.z 3 accept.1m.z 4 finc.1m.z 7 rst.1m.z 7 acct.1m.z 5 format.1m.z 10 runacct.1m.z 5 acctcms.1m.z 4 frec.1m.z 3 sadp.1m.z 6 acctcon.1m.z 13 fsck.1m.z 7 sar.1m.z 3 acctmerg.1m.z 6 fscv.vax.1m.z 3 setmnt.1m.z 4 acctprc.1m.z 10 fsdb.1m.z 3 setmrf.1m.z 14 acctsh.1m.z 4 fts.1m.z 3 shutdown.1m.z 3 acuset.1m.z 4 fuser.1m.z 3 ssr.1m.z 5 bdblk.1m.z 5 fwtmp.1m.z 2 sta.1m.z 4 brc.1m.z 12 getty.1m.z 3 sysdef.1m.z 5 checkall.1m.z 17 init.1m.z 3 tic.1m.z 3 chmap.1m.z 7 install.1m.z 12 trenter.1m.z 3 chroot.1m.z 5 intro.1m.z 4 uucheck.1m.z 3 clri.1m.z 2 ipb.1m.z 3 uucico.1m.z 3 config.3b.1m.z 2 killall.1m.z 5 uuclean.1m.z 17 config.dc.1m.z 2 link.1m.z 6 uucleanup.1m.z 6 cpset.1m.z 13 lpadmin.1m.z 6 uugetty.1m.z 15 crash.1m.z 4 lpsched.1m.z 3 uusched.1m.z 3 cron.1m.z 4 mkboot.1m.z 5 uusub.1m.z 4 dcopy.1m.z 7 mkfs.1m.z 3 uutry.1m.z 3 devnm.1m.z 3 mknod.1m.z 4 uuxqt.1m.z 3 df.1m.z 3 mount.1m.z 3 vcf.1m.z 3 dfcvers.1m.z 5 msi.1m.z 3 vlx.1m.z 8 dgn.1m.z 2 mvdir.1m.z 6 volcopy.1m.z 5 diskusg.1m.z 3 ncheck.1m.z 48 vpmc.dec.1m.z 3 dmkset.1m.z 4 newboot.1m.z 24 vpmc.u3b.1m.z 6 don.1m.z 3 non-btl.1m.z 4 vpmsave.1m.z 3 dskfmt.1m.z 3 pcldaemon.1m.z 6 vpmset.1m.z 5 dstart.1m.z 2 prm.1m.z 5 vpmtest.1m.z 3 errdead.1m.z 4 profiler.1m.z 2 wall.1m.z 3 errdemon.1m.z 3 psel.1m.z 2 whodo.1m 6 errpt.1m.z 3 pwck.1m.z /usr/catman/a_man/man7: total 194 3 hm.7.z 3 osm.7.z 2 tn4.7 4 acu.7.z 4 hp.7.z 3 pcl.7.z 2 tn74.7.z 2 cat.7.z 3 hs.pdp.7.z 2 prf.7.z 3 tn83.7.z 2 dgn.7.z 5 ht.7.z 3 rf.pdp.7.z 2 tn85.7.z 2 dmc.7.z 4 intro.7.z 3 rk.pdp.7.z 5 trace.7.z 3 dmk.7.z 2 kl.pdp.7.z 3 rl.7.z 5 ts11.7.z 7 dsk.7.z 4 kmc.7.z 3 rm80.7.z 2 tty.7.z 2 du.pdp.7.z 4 lp.7.z 3 rp.pdp.7.z 5 tu78.7.z 2 dz.7.z 2 mem.7.z 3 rp07.7.z 4 un32.7.z 2 err.7.z 2 ml11.pdp.7.z 6 sxt.7.z 2 un53.7.z 4 gd.7.z 7 mtc.7.z 31 termio.7.z 2 vp.pdp.7.z 2 gt.7.z 1 null.7.z 5 tm.pdp.7.z 19 vpm.7.z /usr/catman/a_man/man8: total 181 23 780ops.8.z 2 intro.8 7 romboot.8.z 7 3B20boot.8.z 14 crash.dec.8.z 6 ldtape.8.z 4 tapeboot.8.z 5 3B20ops.8.z 9 crash.u3b.8.z 12 mk.8.z 3 unixboot.8.z 13 70boot.8.z 6 diskboot.8.z 14 prm.8.z 16 750ops.8.z 16 eai.8.z 24 rje.8.z /usr/catman/p_man: total 10 2 man2 5 man3 2 man4 1 man5 /usr/catman/p_man/man2: total 339 2 getpid.2.z 3 pipe.2.z 2 sync.2.z 4 access.2.z 2 getuid.2.z 5 plock.2.z 4 sys3b.2.z 4 acct.2.z 41 intro.2.z 4 profil.2.z 2 time.2.z 2 alarm.2.z 3 ioctl.2.z 12 ptrace.2.z 4 times.2.z 4 brk.2.z 5 kill.2.z 5 read.2.z 3 ulimit.2.z 3 chdir.2.z 4 link.2.z 10 semctl.2.z 2 umask.2.z 5 chmod.2.z 4 lseek.2.z 2 semget.2.z 3 umount.2.z 4 chown.2.z 10 maus.2.z 13 semop.2.z 3 uname.2.z 3 chroot.2.z 6 mknod.2.z 2 setpgrp.2.z 4 unlink.2.z 2 close.2.z 4 mount.2.z 3 setuid.2.z 3 ustat.2.z 5 creat.2.z 7 msgctl.2.z 6 shmctl.2.z 5 utime.2.z 3 dup.2.z 6 msgget.2.z 7 shmget.2.z 6 wait.2.z 14 exec.2.z 15 msgop.2.z 7 shmop.2.z 5 write.2.z 5 exit.2.z 3 nice.2.z 15 signal.2.z 5 fcntl.2.z 8 open.2.z 7 stat.2.z 5 fork.2.z 2 pause.2.z 2 stime.2.z /usr/catman/p_man/man3: total 616 5 getc.3s.z 4 nlist.3c.z 3 a64l.3c.z 3 getcwd.3c.z 3 perror.3c.z 2 abort.3c.z 2 getenv.3c.z 6 plot.3x.z 2 abort.3f.z 2 getenv.3f.z 4 popen.3s.z 2 abs.3c.z 6 getgrent.3c.z 15 printf.3s.z 3 abs.3f.z 3 getlogin.3c.z 6 putc.3s.z 2 acos.3f.z 6 getopt.3c.z 3 putenv.3c.z 2 aimag.3f.z 3 getpass.3c.z 3 putpwent.3c.z 2 aint.3f.z 3 getpw.3c.z 3 puts.3s.z 2 asin.3f.z 7 getpwent.3c.z 3 qsort.3c.z 3 assert.3x.z 3 gets.3s.z 2 rand.3c.z 2 atan.3f.z 10 getut.3c.z 2 rand.3f.z 2 atan2.3f.z 12 hsearch.3c.z 10 regcmp.3x.z 4 bessel.3m.z 2 hypot.3m.z 3 round.3f.z 3 bool.3f.z 2 iargc.3f 14 scanf.3s.z 7 bsearch.3c.z 2 index.3f.z 6 setbuf.3s.z 3 clock.3c.z 9 intro.3.z 4 setjmp.3c.z 2 conjg.3f.z 3 l3tol.3c.z 3 sign.3f.z 4 conv.3c.z 3 ldahread.3x.z 2 signal.3f.z 3 cos.3f.z 5 ldclose.3x.z 3 sin.3f.z 2 cosh.3f.z 4 ldfhread.3x.z 2 sinh.3f.z 5 crypt.3c.z 6 ldgetname.3x.z 3 sinh.3m.z 3 ctermid.3s.z 7 ldlread.3x.z 4 sleep.3c.z 8 ctime.3c.z 4 ldlseek.3x.z 3 sputl.3x.z 4 ctype.3c.z 3 ldohseek.3x.z 3 sqrt.3f.z 23 curses.3x.z 7 ldopen.3x.z 6 ssignal.3c.z 3 cuserid.3s.z 4 ldrseek.3x.z 6 stdio.3s.z 10 dial.3c.z 5 ldshread.3x.z 5 stdipc.3c.z 2 dim.3f.z 4 ldsseek.3x.z 2 strcmp.3f.z 2 dprod.3f 4 ldtbindex.3x.z 10 string.3c.z 13 drand48.3c.z 4 ldtbread.3x.z 4 strtod.3c.z 5 ecvt.3c.z 3 ldtbseek.3x.z 4 strtol.3c.z 3 end.3c.z 2 len.3f 2 swab.3c.z 2 erf.3m.z 3 log.3f.z 2 system.3f.z 3 exp.3f.z 3 log10.3f.z 3 system.3s.z 5 exp.3m.z 2 logname.3x.z 2 tan.3f.z 3 fclose.3s.z 7 lsearch.3c.z 2 tanh.3f.z 3 ferror.3s.z 6 malloc.3c.z 2 tmpfile.3s.z 3 floor.3m.z 10 malloc.3x.z 7 tmpnam.3s.z 7 fopen.3s.z 9 matherr.3m.z 5 trig.3m.z 5 fread.3s.z 3 max.3f.z 13 tsearch.3c.z 4 frexp.3c.z 2 mclock.3f.z 3 ttyname.3c.z 5 fseek.3s.z 6 memory.3c.z 2 ttyslot.3c.z 6 ftw.3c.z 3 min.3f.z 3 ungetc.3s.z 9 ftype.3f.z 2 mktemp.3c.z 5 vprintf.3s.z 3 gamma.3m.z 3 mod.3f.z 5 vprintf.3x.z 2 getarg.3f.z 6 monitor.3c.z /usr/catman/p_man/man4: total 313 6 fspec.4.z 5 passwd.4.z 16 a.out.4.z 8 gettydefs.4.z 6 plot.4.z 12 a.out.pdp.4.z 10 gps.4.z 2 pnch.4.z 6 acct.4.z 2 group.4.z 4 profile.4.z 7 ar.4.z 16 inittab.4.z 7 reloc.4.z 3 ar.pdp.4.z 3 inode.4.z 13 sccsfile.4.z 2 checklist.4.z 2 intro.4.z 4 scnhdr.4.z 4 core.4.z 2 issue.4.z 7 syms.4.z 4 cpio.4.z 12 ldfcn.4.z 8 system.4.z 2 dir.4.z 3 linenum.4.z 10 term.4.z 12 errfile.4.z 6 master.dec.4.z 80 terminfo.4.z 4 filehdr.4.z 5 master.u3b.4.z 5 utmp.4.z 12 fs.4.z 3 mnttab.4.z /usr/catman/p_man/man5: total 144 1 intro.5.z 14 mv.5.z 3 types.5.z 4 ascii.5.z 14 man.5.z 4 prof.5.z 5 values.5.z 4 environ.5.z 3 math.5.z 18 regexp.5.z 6 varargs.5.z 6 eqnchar.5.z 3 mm.5.z 3 stat.5.z 3 fcntl.5.z 9 mosd.5.z 5 term.5.z 22 font.5.z 3 mptx.5.z 14 troff.5.z /usr/catman/u_man: total 9 1 local 7 man1 1 man6 [listings of local stuff deleted to save space] /usr/catman/u_man/man1: total 1666 4 diff3.1.z 2 machid.1.z 4 sno.1.z 9 300.1.z 4 diffmk.1.z 4 macref.1.z 14 sort.1.z 3 4014.1.z 2 dircmp.1.z 10 mail.1.z 9 spell.1.z 5 450.1.z 5 dis.1.z 52 mailx.1.z 4 spline.1g.z 12 acctcom.1.z 3 du.1.z 30 make.1.z 2 split.1.z 26 adb.1.z 6 dump.1.z 4 makekey.1.z 4 sroff.1.z 22 admin.1.z 3 dx9700.1.z 2 man.1.z 17 stat.1g.z 8 ar.1.z 2 echo.1.z 2 mesg.1.z 5 strip.1.z 6 ar.pdp.1.z 43 ed.1.z 2 mkdir.1.z 3 strip.pdp.1.z 2 arcv.pdp.1.z 15 edit.1.z 10 mm.1.z 19 stty.1.z 7 as.1.z 6 efl.1.z 5 mmlint.1.z 7 su.1.z 5 as.pdp.1.z 3 enable.1.z 6 mmt.1.z 2 sum.1.z 3 asa.1.z 2 env.1.z 6 net.1c.z 2 sync.1.z 9 at.1.z 13 eqn.1.z 12 newform.1.z 12 tabs.1.z 12 awk.1.z 21 ex.1.z 5 newgrp.1.z 4 tail.1.z 2 banner.1 7 expr.1.z 4 news.1.z 8 tar.1.z 3 basename.1.z 8 f77.1.z 2 nice.1.z 8 tbl.1.z 7 bc.1.z 2 factor.1.z 7 nl.1.z 5 tc.1.z 3 bdiff.1.z 3 file.1.z 8 nm.1.z 2 tee.1 13 bfs.1.z 8 find.1.z 4 nm.pdp.1.z 6 test.1.z 37 bs.1.z 3 fsplit.1.z 4 nohup.1.z 2 time.1.z 2 cal.1.z 6 gdev.1g.z 12 nroff.1.z 5 timex.1.z 3 calendar.1.z 26 ged.1g.z 18 ocw.1.z 7 toc.1g.z 3 cat.1.z 31 get.1.z 3 od.1.z 2 touch.1.z 2 cb.1.z 4 getopt.1.z 7 pack.1.z 3 tplot.1g.z 12 cc.1.z 5 graph.1g.z 5 passwd.1.z 5 tput.1.z 3 cd.1.z 5 graphics.1g.z 6 paste.1.z 5 tr.1.z 9 cdc.1.z 3 greek.1.z 15 pg.1.z 6 troff.1.z 7 cflow.1.z 7 grep.1.z 2 pic.1.z 2 true.1.z 5 chmod.1.z 7 gutil.1g.z 7 pr.1.z 2 tsort.1.z 2 chown.1.z 3 help.1.z 8 prof.1.z 2 tty.1.z 2 cmp.1.z 6 hp.1.z 25 prs.1.z 3 umask.1.z 6 col.1.z 13 hpio.1.z 12 ps.1.z 5 un53ctl.1c.z 6 comb.1.z 2 hyphen.1.z 5 ptx.1.z 2 uname.1.z 2 comm.1.z 2 id.1 2 pwd.1 3 unget.1.z 6 convert.1.z 5 intro.1.z 5 ratfor.1.z 3 uniq.1.z 4 cp.1.z 4 ipcrm.1.z 4 regcmp.1.z 4 units.1.z 8 cpio.1.z 14 ipcs.1.z 6 rjestat.1c.z 13 uucp.1c.z 15 cpp.1.z 5 join.1.z 3 rm.1.z 7 uustat.1c.z 2 cprs.1.z 5 kasb.1.z 4 rmdel.1.z 6 uuto.1c.z 7 crontab.1.z 3 kill.1.z 3 sact.1.z 9 uux.1c.z 5 crypt.1.z 10 ld.1.z 6 sag.1g.z 6 val.1.z 8 csplit.1.z 9 ld.pdp.1.z 8 sar.1.z 10 vc.1.z 6 ct.1c.z 10 lex.1.z 4 scc.1.z 24 vi.1.z 21 ctrace.1.z 2 line.1.z 3 sccsdiff.1.z 3 vpr.1.z 16 cu.1c.z 15 lint.1.z 35 sdb.1.z 2 wait.1.z 6 cut.1.z 5 list.1.z 5 sdiff.1.z 2 wc.1.z 4 cxref.1.z 8 login.1.z 14 sed.1.z 3 what.1.z 5 daps.1.z 2 logname.1.z 28 send.1c.z 9 who.1.z 5 date.1.z 3 lorder.1.z 53 sh.1.z 6 write.1.z 8 dc.1.z 7 lp.1.z 7 shl.1.z 18 x9700.1.z 6 dd.1.z 5 lpstat.1.z 3 size.1.z 13 xargs.1.z 12 delta.1.z 10 ls.1.z 2 size.pdp.1.z 6 yacc.1.z 6 diff.1.z 15 m4.1.z 2 sleep.1.z /usr/catman/u_man/man6: total 49 2 hangman.6.z 6 reversi.6.z 4 arithmetic.6.z 1 intro.6.z 5 sky.6.z 3 back.6.z 3 jotto.6.z 2 ttt.6.z 4 bj.6.z 2 maze.6 2 wump.6.z 3 chess.6.z 2 moo.6.z 6 craps.6.z 4 quiz.6.z >>> >>>4) The system services are logical, consistent, and well-documented. Anything >>> a utility can do, a user program can do too. (And if you want to tickle the >>> kernel, there *is* a thick manual on the system internals.) >> >>Could you then do me a favor. Show me how, in Fortran, I would go about >>setting the protection (no fancy ACL stuff, just basic RWED protections) >>on a file which I am creating. (In C it's easy enough, since the protec- >>tion is specified when the file is created, which of course is tied to the >>straightforward Unix way of doing things!) Please show actual code, such as >>a USEROPEN program, together with the OPEN() statement that calls it, to run >>on VMS 4.2. Or even show me how I can do it in assembler. (I hesitate to >>say show me how to do it in the system programming language, since Bliss-32 >>is an "extra-cost" [and not really very commonly used outside of DEC, unlike >>C which is commonly used outside of Unix systems, let alone AT&T machines] >>option which I don't have. I think the analogy fair since that is what I >>would probably do if I needed to change the protection of a Unix file from >>Fortran [I would call chmod() in a C routine].) >Since I don't write in fortran, I can't give you the exact details, but >the useropen routine should allocate a protection XAB and link it to the FAB >passed into the useropen routine. When the open occurs, the protection >will be right. Well, GEEEEEEEE. With a [SYS,LIB]$EVERYTHING_UNDER_THE_SUN, surely there MUST be a simpler way to do this (or is there?) Some people have suggested using LIB$SPAWN(...,'SET PROTECTION=(whatever) FILENAME.DAT',...) or some system call to change default protections. Trouble is that spawning is a major undertaking under VMS, and changing the default protections in a program I am running has the nasty side effect of leaving them that way for the next program I run (since from DCL all user programs from one DCL session run as part of the same process). >>See also my comments under 2) about the system interface. It is massive, >>complex, and cumbersome, as well as introducing kludges into common pro- >>gramming languages, to be blunt. VMS does indeed pride itself on >>accessibility of system routines from "any" language, but this occurs at >>the cost of kludgey extensions (like Fortran STRUCTUREs and RECORDs and >>%val()s and %loc()s) to common programming languages, that a user would >>actually WANT to program in. C, which is a fairly common, "ordinary" >>programming language and sees wide use and portability even in non-Unix >>environments, fits the UNIX system interface very naturally and needs no >>such kludges to use it. (It is commendable that DEC has seen fit to switch >>rather than fight, and has provided an extensive UNIX-like interface to >>the VMS system within C.) >Fortran structures, records, etc. do not exist for the purpose of kludgey >interfaces to system routines. They exist to enhance fortran's capabilities. >Structures and records provide better programming practices and %val and >%loc allow rather sophisticated pointer operations to be done. Ah, but if those weren't there I'd say it would have a hard time indeed communicating with the OS. Also the %val and %loc and structure and record stuff guarantees incompatibility with any other Fortran in the world. It might be a nice programming language, but it is a superset of Fortran and should be called such. >>> >>>5) VMS, she doesn't die, she doesn't break, she doesn't lose files, she >>> just keeps running along. It's pretty trustworthy. >> >>Oh yes, remember the security hole in VMS 4.1 about a nonprivileged user >>being able to crash the system by entering certain line-editing sequences >>in response to a prompt (involving ^B and some other escape codes). I >>succeeded in doing this once from DCL, and we have a plain VMS system, no >>special private kernel drivers installed. VMS 4.2 also kicked the bucket >>on me the other week when I was trying to access the help library. The >>system just barfed, and the console dump contained my process name. And >>I wasn't even trying any funny business or having any special privileges. >>Needless to say, Unix has never done this kind of thing. >> >Would you mind also including the list of unix kernal bugs that can be activated >by any user to kill the system. Assuming that there is disk space to keep the >list. The above bug makes a good example for you to point to because it >stands out. The reason it stands out is because it is the ONLY bug of it's kind >I have ever seen since about version 2.5 Oh yes, you want ANOTHER bug? What about that ordinary users can make the VMS approximation of "links" (SET FILE/ENTRY) to system files even if they cannot write or read them. Then if a process with proper privileges blows these links away, VMS in its infinite wisdom blows away the CONTENTS of the files as well as the entry! This is not an "accidental" bug either, like the ^B bug was. As for UNIX kernel bugs, I accept the challenge. Any and all interested, please send me C code which I can compile and run as a nonprivileged user on SysVR2 to crash a 3B2, a 3B20, or a VAX, and I will either try it myself (3B2) or submit it to people I know (and trust) to try it on the other machines. >Before you get the idea that I am a rabid UNIX hater, I actually like some >features of unix. I prefer VMS for it's consistancy, reliability and >versatility. There are many unix emulators on VMS because it has the power >and flexability to do a lot of different things easily. I have never seen >a VMS emulator on unix however. And as for the good things about unix, >I have ported or duplicated them on VMS so that I now have the best of both >worlds. >-- > Random (Randy Buckland) > Research Triangle Institute > ...!mcnc!rti-sel!rcb Yes, a UNIX emulator under VMS is improving things. A VMS emulator under UNIX? That would be an interesting research project, but what good would it do?... (And it would of course only work on VAXen. Forget about Amdahls, 3Bs, Pyra- mids,...) The VMS and UNIX paradigms are as different as night and day. -- Daniel R. Levy AT&T Computer Systems Division, Skokie, Illinois ..!ihnp4!ttrdc!levy
friesen@psivax.UUCP (Stanley Friesen) (07/08/86)
In article <873@rti-sel.UUCP> rcb@rti-sel.UUCP (Random) writes: > >>Most Unix programs will print out a line or so of "usage" diagnostics if you >>invoke them with bogus arguments. Do VMS programs do this? >> > >No. VMS programs will not let you invoke them with bogus arguments. Since >the arguments are parsed by DCL before the program is invoked, if you give >too many parameters or an unknown switch DCL will reject it with an error >message that points out the specific problem. Oh, *great*:-) How does the DCL parse the arguments for a user written application program?? I can't see how it can do this without some rather messy interface requirements. This really sounds like a way to make user-written programs second class citizens on the system. I think the individual program is better qualified to analyse its own arguments, whay is really needed is a *standard* for this, like getopts(3)! -- Sarima (Stanley Friesen) UUCP: {ttidca|ihnp4|sdcrdcf|quad1|nrcvax|bellcore|logico}!psivax!friesen ARPA: ??
davidsen@steinmetz.UUCP (07/08/86)
In article <175@esunix.UUCP> loosemor@esunix.UUCP (Sandra Loosemore) writes: >I use both VMS and Un*x every day. I do nearly all my program development >under VMS, though, and I must admit that I like VMS a bit better. There >are a lot of operating systems that are a whole lot worse than Un*x though. >(Fortunately, I don't have to use those every day....) > >I think the greatest advantage VMS offers over Un*x is the networked/shared >file system. VMS has had transparent network file access for at least 5 >years, and this is just now working its way into Un*x. (They just installed >this as a "local hack" on the machines at the University of Utah -- it is >by no means a standard feature yet.) The VMS machines I use at work are >clustered, so the file structure looks exactly the same no matter which >machine I'm using. Given the current trend towards distributed computing >environments with personal workstations and compute servers, shared file >systems are very important things for an operating system to support. A cluster is a special case of a multiprocessor system in which the processors are not allowed to share memory. I personally consider it an artifact of the problems with the 782 which DID share memory. File sharing under VMS is about as non-transparent as you can get! If I want a file on another machine, I type othermach::device:[many.sub.directories]file.typ and to even access a file on another disk on the same machine I need an explicit device name! In UNIX, using NFS (public domain courtesy of Sun) or RFS (ATT) I can use a path of the form: /dir/dir/dir/file and I don't NEED to know if any level of the directory is on another drive or even another machine far away (If it's too far for ethernet, I may guess. Page faulting over a modem doesn't make it) connected by a logical link. NFS will even allow me to mix UNIX and other operating systems, although I have heard some things that make me feel there's room to improve that feature. > >Another thing I like about VMS is the documentation. There is a great deal >of tutorial information and examples in the manuals. It seems like when >I find I need to do something obscure with Un*x, I can never find the >right command to do it (or the documentation is so terse that I'm never >really sure whether it's the right command or not), and I end up having >to ask a "wizard". (Unix sites without "wizards" are really in trouble.) >I also wish Un*x had on-line help on how to use the shell, instead of >just the utilities! I agree that UN*X documentation is terse. I think we have the sh document on line, although it isn't too good in 24 line chunks. The VMS online stuff is too speciffic, as in after help <do something>, you often need to HELP SPECIFY PERMISSIONS, HELP SPECIFY FILENAMES, and HELP SPECIFY otherstuf. Online help frequently lacks examples. The DEC internal manuals for things like internals, mapped sections, message router, etc, are not BETTER than the UN*X manuals, just bigger and prettier. > >I don't think that either VMS or Un*x has serious problems with file system >reliability; I've never lost a file under either OS. File versions under >VMS have saved me more times than I can remember, though. Again, this is >just another place where DEC has taken the trouble to try to "idiot-proof" >things, and we users appreciate it. The system manager often doesn't, though, since s/he has to purge the system or run out of file space. The solution to this was to add disk quotas, and make the user do the purge. If a user needs an editor which makes a backup of a source file, fine. But to make multiple versons of the object and executable? It's not obvious to the user how badly that eats up disk space. > >Of course, there are bad things about VMS too: as others have pointed out, >processes are incredibly slow to start up, the mailer is not too great (but >neither is the Un*x mailer, for that matter), all of the DEC editors are >pretty awful (but so is "vi"), etc. On the whole, though, Un*x is fine if >you want an "open" operating system where you can tweak everything in sight, >but if you just want to get a job done, VMS is a lot less hassle. Actually mailx and Berkeley mail are acceptable user agents in my opinion, if not perfect. Use of some sendmail program to handle domain addressing is needed on any machine with complex connections. Editors are a matter of faith, the only way to get what you want is write it. VMS has very little user help for jobs which are trivial with pipes. It doesn't easily encourage redirection, with "ASSIGN/USER SYS$OUTPUT filename" replacing >file. And don't forget logical names... does this program write SYS$OUTPUT, C$OUTPUT, or whatever. I am not really getting into the VMS vs UNIX(tm) argument so much as pointing out that your perceptions of the strong points of VMS are not universally shared. Another time I'll post my list of good things in VMS for someone else to shoot at. -- -bill davidsen ihnp4!seismo!rochester!steinmetz!--\ \ unirot ------------->---> crdos1!davidsen chinet ------/ sixhub ---------------------/ (davidsen@ge-crd.ARPA) "Stupidity, like virtue, is its own reward"
g-rh@cca.UUCP (07/09/86)
In article <> friesen@psivax.UUCP (Stanley Friesen) writes: >In article <873@rti-sel.UUCP> rcb@rti-sel.UUCP (Random) writes: >> >>>Most Unix programs will print out a line or so of "usage" diagnostics if you >>>invoke them with bogus arguments. Do VMS programs do this? >>> >> >>No. VMS programs will not let you invoke them with bogus arguments. Since >>the arguments are parsed by DCL before the program is invoked, if you give >>too many parameters or an unknown switch DCL will reject it with an error >>message that points out the specific problem. > > Oh, *great*:-) How does the DCL parse the arguments for a user >written application program?? I can't see how it can do this without >some rather messy interface requirements. This really sounds like a >way to make user-written programs second class citizens on the system. >I think the individual program is better qualified to analyse its own >arguments, whay is really needed is a *standard* for this, like getopts(3)! I'm not a VMS guru but I know enough to know that this is all getting a little confused. VMS programs which are not installed can be executed either with RUN or MCR. RUN is a general utility for executing a user application program; MCR is another such utility with somewhat different rules. In particular, arguments cannot be passed to programs invoked using RUN; however they can for programs invoked using MCR. System programs take options in the form of switches. Thus: run xyz mcr xyz arg1 arg2 arg3 dir/col=1 [DIR is the equivalent of ls. The slash signifies a switch (option). In this case the output is one column per line.] I don't know the rules for creating commands using switches. (My impression is that is done as part of installation -- but I just don't know.) In any case the DCL switch parser is the equivalent for VMS of getopts for publicly known programs. The difference is that you have to describe to the system what rules your options (switches) follow if your program is a public program. When your program is invoked the DCL validates the arguments before the program is brought up. DISCLAIMER -- this is just my impression; someone with VMS systems experience should clarify the matter. However, if my understanding is correct, then this is a perfectly reasonable way to do things -- I would count it as preferable since it insists that options in public (system wide) utilities be handled in a standardized manner. Richard Harter SMDS Inc.
QAA@PSUVM.BITNET (07/09/86)
> > Oh, *great*:-) How does the DCL parse the arguments for a user >written application program?? I can't see how it can do this without >some rather messy interface requirements. This really sounds like a >way to make user-written programs second class citizens on the system. >I think the individual program is better qualified to analyse its own >arguments, whay is really needed is a *standard* for this, like getopts(3)! >-- > > Sarima (Stanley Friesen) > >UUCP: {ttidca|ihnp4|sdcrdcf|quad1|nrcvax|bellcore|logico}!psivax!friesen >ARPA: ?? VMS allows *TWO* ways for an image (with parameters) to be activated. If you so choose, you may have your application parse ALL of the command line, spending tons of worthless cpu time deciding what is right and what is wrong, or you can opt to have DCL parse the command line for you. In EITHER case, it is YOUR decision as to which parameters or qualifiers are valid, etc. In the first case, your program would make a call to a library function called LIB$GET_FOREIGN(...) and magically you would be given everything typed past the command name. From that point on, it's your responsibility to parse the mess you get. The other alternative is to write a "command definition" file which describes EXACTLY to DCL what qualifiers or parameters are valid, which ones can be use together, which ones require a value, which ones have default values, etc.. Sounds pretty powerful to me! DCL will even PROMPT for missing parameters with a prompt that YOU decide on! All your program has to do then is to call special routines to pick up this information. For example, to get the value of the qualifier "/REMOTE" all you would do is call a routine called CLI$GET_VALUE('REMOTE'...) Magically you get a string returned which contains the "value" of the qualifier. I don't see this interface as kludgy in any way, I consider it an elegant interface to a complex parsing routine called DCL. For more on how this all works, check out the Command Definition Utility in the Utilities Ref. Manual. (You might be surprised) Ever considered checking the manuals BEFORE complaining about this or that? Cheers, Tim Bieling, System Manager - Architecture Computer Lab Penn State University Bitnet: Bieling@Psuarch
jim@oswald.UUCP (Jim Olsen) (07/10/86)
In article <1320@psivax.UUCP> friesen@psivax.UUCP (Stanley Friesen) writes: > Oh, *great*:-) How does the DCL parse the arguments for a user >written application program?? I can't see how it can do this without >some rather messy interface requirements. This really sounds like a >way to make user-written programs second class citizens on the system. >I think the individual program is better qualified to analyse its own >arguments, whay is really needed is a *standard* for this, like getopts(3)! On the contrary, user-written programs under VMS are not second-class citizens in this respect. There is a fully documented facility for telling DCL how to parse the command line. This facility is used by system and user programs alike. As to whether it's better to have the program or the system parse the command line, I think that's a matter of taste. However, having the system do the parsing makes it easier to encourage standardization.
levy@ttrdc.UUCP (Daniel R. Levy) (07/10/86)
In article <1320@psivax.UUCP>, friesen@psivax.UUCP (Stanley Friesen) writes: >In article <873@rti-sel.UUCP> rcb@rti-sel.UUCP (Random) writes: >>>Most Unix programs will print out a line or so of "usage" diagnostics if you >>>invoke them with bogus arguments. Do VMS programs do this? >>No. VMS programs will not let you invoke them with bogus arguments. Since >>the arguments are parsed by DCL before the program is invoked, if you give >>too many parameters or an unknown switch DCL will reject it with an error >>message that points out the specific problem. > Oh, *great*:-) How does the DCL parse the arguments for a user >written application program?? I can't see how it can do this without >some rather messy interface requirements. This really sounds like a >way to make user-written programs second class citizens on the system. >I think the individual program is better qualified to analyse its own >arguments, whay is really needed is a *standard* for this, like getopts(3)! > Sarima (Stanley Friesen) >UUCP: {ttidca|ihnp4|sdcrdcf|quad1|nrcvax|bellcore|logico}!psivax!friesen >ARPA: ?? To be fair, it is possible to set a user program up to receive command line arguments which have been pre-parsed by DCL, but the procedure is indeed slightly "messy" (special library functions must be called from the user program, and DCL must be told explicitly (as in the login procedure) about a file containing a description of how DCL is to parse the arguments, qualifiers, etc. for user commands. (It is also possible to set up a user program as a "foreign" command, whereby it is defined as a "symbol" [kind of like a ksh or csh "alias"] and an image of the command line can be accessed through a special library function by the program thus invoked.) However, even at best DCL "diagnostics" can be ambiguous. For example, $ SHOW USERS/BOGUS gets me the diagnostic %DCL-W-IVQUAL, unrecognized qualifier - check validity, spelling, and placement \BOGUS\ Hardly pointing out the specific problem! Better something like this (under System V): $ who -bogus who: illegal option -- o Usage: who [-rbtpludAasHTq] [am i] [utmp_like_file] r run level b boot time t time changes p processes other than getty or users l login processes u useful information d dead processes A accounting information a all (rbtpludA options) s short form of who (no time since last output or pid) H print header T status of tty (+ writable, - not writable, x exclusive open, ? hung) q quick who -- ------------------------------- Disclaimer: The views contained herein are | dan levy | yvel nad | my own and are not at all those of my em- | an engihacker @ | ployer or the administrator of any computer | at&t computer systems division | upon which I may hack. | skokie, illinois | -------------------------------- Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa, vax135}!ttrdc!ttrda!levy
rcb@rti-sel.UUCP (Random) (07/10/86)
In article <1320@psivax.UUCP> friesen@psivax.UUCP (Stanley Friesen) writes: >In article <873@rti-sel.UUCP> rcb@rti-sel.UUCP (Random) writes: >> >>>Most Unix programs will print out a line or so of "usage" diagnostics if you >>>invoke them with bogus arguments. Do VMS programs do this? >>> >> >>No. VMS programs will not let you invoke them with bogus arguments. Since >>the arguments are parsed by DCL before the program is invoked, if you give >>too many parameters or an unknown switch DCL will reject it with an error >>message that points out the specific problem. > > Oh, *great*:-) How does the DCL parse the arguments for a user >written application program?? I can't see how it can do this without >some rather messy interface requirements. This really sounds like a >way to make user-written programs second class citizens on the system. >I think the individual program is better qualified to analyse its own >arguments, whay is really needed is a *standard* for this, like getopts(3)! >-- > Sarima (Stanley Friesen) Have you ever possibly considered finding out about something before talking about. It will usually make you look a lot less like a fool. The DCL command definitions simply define how many parameters can be used, which ones are optional, the possible switches, The possible switch locations, and the possible types for parameters and switches. It can also be used to change the default values based on interactive or batch operation. The possible types are simply string, number, file, acl, etc. and also one of a list of user defined keywords. DCL is capable of parsing these properly because you give it a definition that defines all these possibilities. Also, one of the possibilities is type=rest_of_line which will turn off all parsing and make the rest of the line be one parameter. The advantages it gives you are that if you give it too many parameter, it give you an error message. If you give it too few, it will prompt for what it needs. If a switch requires a value and you don't give it one, it will issue an error. If a switch does not take a value and you giv it one, it will issue an error. If you give a string to a parameter of type number you get an error message. And if you use a switch that is not defined, you get an error. Beyond type checking, it does not try to interpret your parameters and switch values. An example of the definition file follows so that you might know what you are maligning. ! The TeX command define verb tex image tex_base:[programs]tex parameter p1, label=input_file parameter p2, label=second_file qualifier font_directory, label=font_area, nonnegatable, value(list) qualifier input_directory, label=input_area, nonnegatable, value(list) qualifier batch, batch Simple, clean and easy to use. Definable on a per user basis, defined for a group of users by the system manager or on a system wide basis. The program interface is also clean. To get the values, you only have to issue the following call. call dcl$get_value ("input_area", string_variable) and you have it. Easy, no? So, next time, ask someone about a feature you know nothing about before you go shooting off your mouth (or keyboard). -- Random (Randy Buckland) Research Triangle Institute ...!mcnc!rti-sel!rcb
iwm@icdoc.UUCP (07/10/86)
In article <1320@psivax.UUCP> friesen@psivax.UUCP (Stanley Friesen) writes: >> >>No. VMS programs will not let you invoke them with bogus arguments. Since >>the arguments are parsed by DCL before the program is invoked, if you give >>too many parameters or an unknown switch DCL will reject it with an error >>message that points out the specific problem. > > Oh, *great*:-) How does the DCL parse the arguments for a user >written application program?? I can't see how it can do this without >some rather messy interface requirements. This really sounds like a >way to make user-written programs second class citizens on the system. >I think the individual program is better qualified to analyse its own >arguments, whay is really needed is a *standard* for this, like getopts(3)! Well I find its a very nice interface: 1 Define the syntax in a text form in a command definition file eg: DEFINE VERB CRASH IMAGE "USER_GAMES:DIE.EXE" PARAMETER P1,LABEL=TIME,VALUE(PROMPT="When?,TYPE=$DATETIME) 2 Write your program and use two interface functions to check if items are pressent and get their values, using the label to refer to them. 3 Install the command by typing SET COMMAND filename - when and where you do this depends on who you want to see the definition. I like this because : All the prompting, syntax checks etc are done for you, it is possible to list mutually exclusive options and have that checked too. Data type checks can be specified - the example will only allow a valid date/time, and will even convert CRASH TOMORROW into the real date for me! The real winner is that it is the SAME parser for all commands. I have problems with any system that forces each program to parse its args (CMS, NOS, UNIX...) - by all means use getopt, but who is going to rewrite existing programs and manuals? -- Ian W Moor UUCP: seismo!mcvax!ukc!icdoc!iwm ARPA: iwm%icdoc@ucl Department of Computing Whereat a great and far-off voice was heard, saying, Imperial College. Poop-poop-poopy, and it was even so; and the days 180 Queensgate of Poopy Panda were long in the land. London SW7 Uk.
jw@astgb1.UUCP (John Woodruff) (07/11/86)
In article <1320@psivax.UUCP>, friesen@psivax.UUCP (Stanley Friesen) writes: > Oh, *great*:-) How does the DCL parse the arguments for a user > written application program?? It's called SET COMMAND... you write a description of your command, parameters, options, etc., including the runnable image name; and give it to DCL. Then you call a number of CLI$GETxxxx's for each one. Quite easy, in fact... I did it from Fortran. I only wish that the .CLD included documentation, and that HELP knew about the DCL tables for such things as HELP xxx /PARAM. I've been away from VMS for 3 years, and prefer Unix. But let's give VMS her due...
garry@batcomputer.TN.CORNELL.EDU (Garry Wiegand) (07/11/86)
In a recent article levy@ttrdc.UUCP (Daniel R. Levy) wrote: >Hardly pointing out the specific problem! Better something like this (under >System V): > >$ who -bogus >who: illegal option -- o >Usage: who [-rbtpludAasHTq] [am i] [utmp_like_file] > >r run level >b boot time >t time changes >... My goodness! I never *ever* saw a Unix program actually use English words and list out the options! What won't they think of next!!!! (As for me, I've always rather enjoyed those clever little "Usage: oink -azmnblooglefungaaa" lines.) More seriously, there pros and cons to this approach - if I just fumble-fingered, and the program has a gazillion options, I DON'T want to wait while they all scroll by. PS - On my system (4.3 BSD), typing "who -bogus" yields: who: cannot open utmp This excellent message is *much more* in the tradition of the Unix. -- garry wiegand (garry%cadif-oak@cu-arpa.cs.cornell.edu)
jrw@hropus.UUCP (07/12/86)
> PS - On my system (4.3 BSD), typing "who -bogus" yields: > > who: cannot open utmp > vvv :-) > This excellent message is *much more* in the tradition of the Unix. /^^ When did BSD become/ This whole discussion is becoming quite comical. Let's face it, both os's have their supporters and flamers. But to say that Unix is better because it has better usage messages is even more comical. I happen to like its terse mesaages, because without them, there would be no need to hire wizards, for then, who would be around to answer questions about what "awk: bailing out near line 1" or "uux partially failed" REALLY MEAN.... -- Jim Webb "Out of phase--get help" ihnp4!houxm!hropus!jrw
tihor@acf4.UUCP (07/12/86)
>/* acf4:net.unix / davidsen@steinmetz.UUCP / 1:46 pm Jul 8, 1986 */ I believe that Mr. Steinmetz has misunderstood the term "Transparent file sharing" in his comment: > File sharing under VMS is about as non-transparent as you can get! >If I want a file on another machine, I type othermach::device:[many.sub.directories]file.typ The term has most often been used to mean Transparent to the application using the file, not "syntacticly invisible to the use" (although that property has considerable appeal in many cases.) In this sense DECnet file access as implemented in VMS and some other DECnet libraries is indeeed highly transparent. Very few operations on XYZ::FRED.LIS are forbidden that wouldbe permitted on FRED.LIS. W/R/T VAXcluster they should be viewed as loosely coupled multiprocessors which currently share (principly) their file systems. In the long run they seem to be evolving into full if loosely coupled multiprocessors. The fact that they share separate but cooperating system images that can fail separately is an important characteristic and very different from some tightly coupled multiprocessors which will only fail together.
garry@batcomputer.UUCP (07/14/86)
In a recent article g-rh@cca.UUCP (Richard Harter) wrote: > I'm not a VMS guru but I know enough to know that this is all >getting a little confused... >... >mcr xyz arg1 arg2 arg3 >... There is ample confusion here already just explaining "foreign" and "DCL table" commands -- you're not helping!! (For those who want to know - "mcr" is a leftover from version 1 VMS. It was intended for use in running "compatibility mode" images. It DOES also happen to work on "native mode" images, but the defaulting is weird - "xyz" defaults to SYS$SYSTEM rather than the local directory. I would recommend using "foreign" definitions instead, especially for system utilities. Users of "mcr" should be suspected of being wizards.) -- garry wiegand (garry%cadif-oak@cu-arpa.cs.cornell.edu)
rcb@rti-sel.UUCP (07/14/86)
> >However, even at best DCL "diagnostics" can be ambiguous. For example, > >$ SHOW USERS/BOGUS > >gets me the diagnostic > >%DCL-W-IVQUAL, unrecognized qualifier - check validity, spelling, and placement > \BOGUS\ > >Hardly pointing out the specific problem! Better something like this (under >System V): Seems reasonable to me. "/bogus" is unknown at that place. Could be in wrong place or spelled wrong. > >$ who -bogus >who: illegal option -- o >Usage: who [-rbtpludAasHTq] [am i] [utmp_like_file] > >r run level >b boot time >t time changes >p processes other than getty or users >l login processes >u useful information >d dead processes >A accounting information >a all (rbtpludA options) >s short form of who (no time since last output or pid) >H print header >T status of tty (+ writable, - not writable, x exclusive open, ? hung) >q quick who I have NEVER seen a unix error message like this! At best I have seen $ who -bogus who: illegal option -- o or $ who -bogus Usage: who [-rbtpludAasHTq] [am i] [utmp_like_file] Of which I prefer the first as it at least tells me what I did wrong. -- Random (Randy Buckland) Research Triangle Institute ...!mcnc!rti-sel!rcb
tim@ism780c.UUCP (07/17/86)
In article <6424QAA@PSUVM> QAA@PSUVM.BITNET writes: > >If you so choose, you may have your application parse ALL of the >command line, spending tons of worthless cpu time deciding what is >right and what is wrong, or you can opt to have DCL parse the command >line for you. In other words, you can spend tons or worthless CPU time, or you can let DCL spend tons or worthless CPU time. Or are you trying to say that DCL can parse arguments without using CPU time? -- Tim Smith USENET: sdcrdcf!ism780c!tim || ima!ism780!tim "hey, bay-BEE'...hey, bay-BEE'" Compuserve: 72257,3706 Delphi || GEnie: mnementh
davidsen@steinmetz.UUCP (Davidsen) (08/04/86)
I apologise for the length of this, I cut it as much as posible. Readers have to see the pro-UNIX posting (mildly sarcastic) and the pro-VMS reply (rude and personal) to appreciate my answer about the technical shortcomings of the answer. In article <909@rti-sel.UUCP> rcb@rti-sel.UUCP (Random) writes: >In article <1320@psivax.UUCP> friesen@psivax.UUCP (Stanley Friesen) writes: >>In article <873@rti-sel.UUCP> rcb@rti-sel.UUCP (Random) writes: >>> the original pro-VMS statement >>>No. VMS programs will not let you invoke them with bogus arguments. Since >>>the arguments are parsed by DCL before the program is invoked, if you give >>>too many parameters or an unknown switch DCL will reject it with an error >>>message that points out the specific problem. >> the somewhat sarcastic reply >> Oh, *great*:-) How does the DCL parse the arguments for a user >>written application program?? I can't see how it can do this without >>some rather messy interface requirements. This really sounds like a >>way to make user-written programs second class citizens on the system. >>I think the individual program is better qualified to analyse its own >>arguments, whay is really needed is a *standard* for this, like getopts(3)! >>-- >> Sarima (Stanley Friesen) > the vituperative personal attack >Have you ever possibly considered finding out about something before >talking about. It will usually make you look a lot less like a fool. followed by a correct but incomplete technical rebuttal! >The DCL command definitions simply define how many parameters can be used, >which ones are optional, the possible switches, The possible switch locations, >and the possible types for parameters and switches. It can also be used >to change the default values based on interactive or batch operation. >The possible types are simply string, number, file, acl, etc. and also >one of a list of user defined keywords. DCL is capable of parsing these >properly because you give it a definition that defines all these possibilities. ... another 30 lines or so of "simple" explanation deleted ... No one in their right mind could consider this "simple". > >An example of the definition file follows so that you might know what you >are maligning. ... 13 lines of more "simple" stuff deleted ... loaded with keywords ... >Simple, clean and easy to use. Definable on a per user basis, defined for >a group of users by the system manager or on a system wide basis. The program ^^^^^^^^^^^^ That's convenient. >interface is also clean. To get the values, you only have to issue the >following call. > > call dcl$get_value ("input_area", string_variable) > >and you have it. Easy, no? So, next time, ask someone about a feature you ^^^^^^^^^ in a word **NO**. To write a program asking about the calling sequence instead of typing the command at the prompt is not by any stretch of definition "easy". >know nothing about before you go shooting off your mouth (or keyboard). ^^ more tact and courtesy ^^ What really made this answer so obnoxious is that after all this overkill flame, the poster didn't say (or, could it be, didn't know) that the user can define his/her commands with a mechanism similar to an alias, and get no parameter checking at all. It can even be put in a startup file and done at login. Examples: (! starts comments) $ check:==$usr$disk:[user.bin]check.exe ! binary executable image $ redo:==@usr$disk:[user.bin]redo.com ! DCL (shell) command file ^ ^ ^ ^ ^ ^ ^ | | | | | | |__ filename | | | | | |_______ subdirectory | | | | |____________ user directory | | | |____________________ device (may be logical = directory) | | |________________________ $ for binary, @ for DCL shell | |__________________________ mystic assignment operator |______________________________ symbol now defined as valid command I hope this has spread some rational light on the subject. The ability to have the arguments parsed is very useful, but time consuming for the system operator. The method described above provides no checking, but is easily doable by the user. It is far easier to write commands knowing that they will never get bad arguments than to put recovery code in each and every program. VMS provides both. Please don't count me as pro-VMS, I have used it since we got our first VAX (I believe it was S/N < 30) and still only consider it acceptable. I find the UNIX interface more convenient and the response far better for small programs due to the overhead of process start in VMS. Flamers, please MEASURE the overhead for UNIX and VMS on similar machines (in cpu or disk access) before rebutting this. -- -bill davidsen ihnp4!seismo!rochester!steinmetz!--\ \ unirot ------------->---> crdos1!davidsen chinet ------/ sixhub ---------------------/ (davidsen@ge-crd.ARPA) "Stupidity, like virtue, is its own reward"
taylor@glasgow.glasgow.UUCP (Jem Taylor) (08/11/86)
In article <859@kbsvax.steinmetz.UUCP> davidsen@kbsvax.UUCP (Davidsen) writes: >In article <909@rti-sel.UUCP> rcb@rti-sel.UUCP (Random) writes: >>In article <1320@psivax.UUCP> friesen@psivax.UUCP (Stanley Friesen) writes: >>>In article <873@rti-sel.UUCP> rcb@rti-sel.UUCP (Random) writes: >>>> > the original pro-VMS statement >>>>No. VMS programs will not let you invoke them with bogus arguments. Since >>>>the arguments are parsed by DCL before the program is invoked, if you give >>>>too many parameters or an unknown switch DCL will reject it with an error >>>>message that points out the specific problem. ... >overkill flame, the poster didn't say (or, could it be, didn't know) >that the user can define his/her commands with a mechanism similar to >an alias, and get no parameter checking at all. It can even be put in a >startup file and done at login. > >Examples: (! starts comments) > $ check:==$usr$disk:[user.bin]check.exe ! binary executable image > $ redo:==@usr$disk:[user.bin]redo.com ! DCL (shell) command file > | | |________________________ $ for binary, @ for DCL shell > | |__________________________ mystic assignment operator > |______________________________ symbol now defined as valid command > mystic, yes, but powerful. And much of unix is mystic of course ... = and := are 'local' symbol assigns - like 'set' == and :== are 'global' - like setenv (except that unlike set and setenv, these things are _also_ usable as aliases as in csh ) the ':' suppresses symbol substition on the RHS unless the symbol is explicitly quoted. Thus A == B and A:== 'B' are equivalent. If you don't use ':', you need '"' around strings. The example here sets C to a string, rather than A to the VALUE OF B as above : C == "text" or C :== text Like everything, once you are used to it, it's fine. >I hope this has spread some rational light on the subject. The ability >to have the arguments parsed is very useful, but time consuming for the >system operator. The method described above provides no checking, but >is easily doable by the user. It is far easier to write commands >knowing that they will never get bad arguments than to put recovery >code in each and every program. VMS provides both. > It's NOT time consuming for the operator. The .CLD (Command language definition) of a command is written by the author at the same time as the command. I write my .CLD first, then the .HLP ( Help ) input for the LIBRARY/HELP command, and finally code the command itself. This ensures that the command interface is properly defined and that the help page is true; finally the code has to conform to the definition. The .HLP file is incorporated into the system help library at installation of the command, and the .CLD is incorporated into the system command table at the same time - once only. This is akin to putting the files into /bin and /usr/man (or wherever) - which always strikes me as rather ad hoc, the set of available commands being a one-to-one mapping to the contents of certain directories of the filestore. One very powerful aspect of .CLD which no-one mentions is the 'image' keyword, which defines where the executable image is to be found. If no image is specified, SYS$SYSTEM:command_name.EXE is assumed, but the file can be put anywhere and need not have the same name as the command. Even more powerful is the use in this example: define verb mycommand image userdisk:[mydir]mycommand1.exe .... qualifier special syntax=otherformat define syntax otherformat image otherdisk:[mydir]mycommand2.exe with this definition, 'myco' (DCL supports unique truncation of the command verb) will invoke the image mycommand1, but 'mycom/spe' enforces the alternate syntax of the command and invokes a different image. This means that a number of different programs can be given the same name, as in DEFINE (define a logical name for a device), DEFINE/KEY (redefine the keyboard) etc, but invoke unrelated images. I have used this mechanism to support the use of two images with common code, one small and fast for the common options, the other more powerful but larger and slower. Users need not know that they are using different images, and do not need to remember which of 'prog', 'xprog' or 'nprog3' they should be using this week. >Please don't count me as pro-VMS, I have used it since we got our first >VAX (I believe it was S/N < 30) and still only consider it acceptable. >I find the UNIX interface more convenient and the response far better >for small programs due to the overhead of process start in VMS. >Flamers, please MEASURE the overhead for UNIX and VMS on similar >machines (in cpu or disk access) before rebutting this. In my experience of VMS 782's and 785's versus Unix 750's and 780's, I find the above to be true ( SPAWN takes an age in VMS ), but the VMS systems seem to degrade more gracefully when too many users are logged on. The Unix system seems to give up completely when overloaded. Obviously page and swap space tuning and the myriad sysgen parameters under VMS give a diligent system manager more scope to fit the machine to the performance demanded of it. -Jem. I'm very happy with my 42nix WCW MG-1 workstation - thou' it did crash completely the other day when I put 25+ clocks on the screen, all with the second hand moving, and tried to move them around *fast*. -- ________________________________________________________________________________ JANET: taylor@uk.ac.glasgow.cs -o Jemima USENET: {ukc,ucl-cs}!cs.glasgow.ac.uk!taylor (=-) Puddleduck ARPANET: taylor%cs.glasgow.ac.uk@ucl-cs.arpa Phone: +44 (0)41 339-8855 extn. 6054 Mail: J.A.Taylor, Computer Science, 17 Lilybank Gardens, GB-GLASGOW G12 8QQ ________________________________________________________________________________