jps@apollo.uucp (Jeffrey P. Snover) (05/05/87)
>I know that bsd unix outperforms vms; I also know by >experience that vms interfaces (to programs and other >users) are quite bad. I am so stunned by this comment I don't know where to begin. You left your thinking cap at home today didn't you? You "KNOW" that bsd unix outperfoms vms do you? What is the basis of this "KNOWLEDGE". If you have this "KNOWLEDGE", as you claim, then why are you posting this request. VMS interfaces "are quite bad" ? REALLY! I have worked with both UNIX and VMS for many years and whereas VMS does have its weakness, I don't think that any sentine are All I need are plain figures (not opinions) obtained in a machine able to run both (say, a vax 750). For instance number of interrupts caused by buffered i/o, paging, system calls, total number of interrupts, etc. Maybe timing of some typical programs...
jps@apollo.UUCP (05/05/87)
Lets try that one more time... >I know that bsd unix outperforms vms; I also know by >experience that vms interfaces (to programs and other >users) are quite bad. I am so stunned by this comment I don't know where to begin. You left your thinking cap at home today didn't you? You "KNOW" that bsd unix outperfoms vms do you? What is the basis of this "KNOWLEDGE". If you have this "KNOWLEDGE", as you claim, then why are you posting this request. VMS interfaces "are quite bad" ? REALLY! I have worked with both UNIX and VMS for many years and whereas VMS does have its weakness, I don't think that any sentient entity could say that its interfaces "are quite bad". And another thing. VMS is written/controlled by people who give a sh*t. They care whether it works or not and they attempt to bring this attitude out in their product. UNIX one the other hand, (even though I love it) really doesn't care whether it works or not. The attitude seems to be one of "If I can make a funny remark or witty comment about the inadequancies of the program, then I don't have to make it work." Thats why "FIND" is documented with: "BUGS: The syntax is very painfull." If they cared, they'd fix it. But no, its "HO HO HO thats so funny, isn't UNIX great. Oh yea man, thats like ""double panic"" right before your machine is about to be hosed HA HA HA. How about all those wicked funny error messages that come up while your trying to patch the file system yuk yuk."
chris@mimsy.UUCP (Chris Torek) (05/06/87)
In article <34ab3c5c.8be4@apollo.uucp> jps@apollo.uucp (Jeffrey >P. Snover) writes: >VMS is written/controlled by people who give a sh*t. As with any other large group, some do, and some do not. Listen to some of the `horror stories' about SPRs and nasty kernel bugs that are sent to the comp.os.vms (info-vax in ARPAland) group. >... UNIX one the other hand, (even though I love it) really doesn't >care whether it works or not. Obviously an operating system does not care whether it itself works, unless you have done what all the AI people are still attempting. >The attitude seems to be one of "If I can make a funny remark or >witty comment about the inadequancies of the program, then I don't have >to make it work." Thats why "FIND" is documented with: > "BUGS: The syntax is very painfull." >If they cared, they'd fix it. Not so. It is true that the very name `BUGS' is meant in jest; but while stodgier names include `LIMITATIONS' and `RESTRICTIONS', the contents of these sections in other systems' manuals are identical. `Fixing' the syntax of find would be a disservice, for it is now too well engrained. It would be like asking VMS to fix the (to me painful) syntax of qualifiers. >But no, its "HO HO HO thats so funny, isn't UNIX great. Oh yea >man, thats like ""double panic"" right before your machine is about >to be hosed HA HA HA. How about all those wicked funny error >messages that come up while your trying to patch the file system >yuk yuk." If you speak of `?CPU DBL-ERR HALT', this is a console message built into Vax 11/780s, and occurs under VMS with equal frequency, and often equal consequences. I cannot imagine what other `wicked funny error messages' you refer to. VMS is a remarkably modern operating system. It is *not* a model of perfection. It *is* a supported system. 4BSD Unix is primarily a research vehicle; for support you must go to Mt. Xinu, or use Ultrix or System `pick a release, any release' V or whatnot. Oddly enough, I find all of the supported systems less useful. Maybe it is because we are a research department. (More likely it is because we get sources without hassles.) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) Domain: chris@mimsy.umd.edu Path: seismo!mimsy!chris
steven@pearl.berkeley.edu (Stephen the Greatest) (05/16/87)
In article <34ab0e42.8be4@apollo.uucp> jps@apollo.uucp (Jeffrey P. Snover) writes: > >>I know that bsd unix outperforms vms; I also know by >>experience that vms interfaces (to programs and other >>users) are quite bad. > >I am so stunned by this comment I don't know where to begin. >You left your thinking cap at home today didn't you? >You "KNOW" that bsd unix outperfoms vms do you? What is the >basis of this "KNOWLEDGE". If you have this "KNOWLEDGE", >as you claim, then why are you posting this request. > >VMS interfaces "are quite bad" ? REALLY! I have worked >with both UNIX and VMS for many years and whereas VMS >does have its weakness, I don't think that any sentine I have been working intensively with 4.3BSD UNIX and VAX/VMS V4.?. I think VMS definitely out-performs UNIX in number-crunching operations, but UNIX is strong in its I/O interface. Also, I hate the shell (or command inter- pretor) in VMS. Why can't anybody in DEC write something like C-Shell? I think VMS is absolutely able to support a C-Shell-like command interface. Also, the primary language for VMS (as least I think) is FORTRAN while UNIX is C. This does tells us something about the strengths of each operating systems. Personally, I like BSD UNIX better. - Stephen Chung
dhesi@bsu-cs.UUCP (Rahul Dhesi) (05/19/87)
In article <3583@jade.BERKELEY.EDU> steven@pearl.berkeley.edu (Stephen the Greatest [or so he claims]) says this about VAX/VMS: > ...Also, I hate the shell (or command inter- >pretor) in VMS. Why can't anybody in DEC write something like C-Shell? >I think VMS is absolutely able to support a C-Shell-like command interface. VMS is not able to support a C-Shell-like command interface for a rather important reason. The UNIX shell interface depends heavily on process creation and many commands create several processes. VAX/VMS is extremely inefficient at creating new processes. When the VMS command interpreter executes a user program, it does not create a new process, but simply does the equivalent of a UNIX exec() system call. Thus the current invocation of the command interpreter effectively dies and is replaced by the user program. (How it regains control after the user program terminates is a long, long story that I don't fully understand.) The inability to create a process efficiently (it can take about 2 to 6 seconds to create a new process on a typical VMS system under a typical load) leads to all sorts of problems. You will note that VMS utilities do not let you escape to a command shell easily (most do not let you do that AT ALL). If you could escape to a command shell (which would involve creating a new process), you would notice the slow speed. But since users are not allowed to do most things that could reveal VMS's inefficiency, they frequently begin to believe that VMS is more efficient. They often quickly change their mind when they use something like DEC's All-In-One software, which uses multiple processes. The above does not prevent DEC from providing a structured shell programming language. However, the command language (modestly named DEC Comamnd Language) appears to have a batch environment as its design basis, and has very little "memory" of past statements executed. In a batch enviroment, where each control card is separately interpreted, it is difficult to provide control structures such as if..then..else...endif, while and for loops, etc. More evidence that DCL has little or no memory: there is no way of giving multiple commands on the same line. To properly handle multiple commands, the command interpreter would have to save the previous partially-executed command line somewhere. But since the command interpreter effectively does an exec() each time it executed a user command, it can't save information and reuse it very easily--the next command is really executed by a brand-new invocation of the command interpreter. I am only speculating here, but I haven't heard any better explanations of why DCL is oriented towards a one-command-one-line-only-no-control- structures command interface. Then again, the VMS mail utility has no Cc: field. Great Mysteries of Our Time. -- Rahul Dhesi UUCP: {ihnp4,seismo}!{iuvax,pur-ee}!bsu-cs!dhesi
jbs@eddie.MIT.EDU (Jeff Siegal) (05/19/87)
In article <3583@jade.BERKELEY.EDU> steven@pearl.berkeley.edu (Stephen the Greatest) writes: >Also, the primary language for VMS (as least I think) is FORTRAN while UNIX >is C. Actually, the "primary language" (whatever that means) is probably Assembler (MACRO-32), since that comes with every /VMS system, while Fortran is a separate product that costs significant extra $. Jeff
jbwaters@bsu-cs.UUCP (J. Brian Waters) (05/19/87)
In article <3583@jade.BERKELEY.EDU>, steven@pearl.berkeley.edu (Stephen the Greatest) writes:
.> Also, the primary language for VMS (as least I think) is FORTRAN while UNIX
.> is C. This does tells us something about the strengths of each operating
.> systems. Personally, I like BSD UNIX better.
.>
.> - Stephen Chung
In the for what it is worth dept., VMS is primarly written in BLISS.schwartz@swatsun.UUCP (05/19/87)
In article <667@bsu-cs.UUCP>, dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: > But since the command > interpreter effectively does an exec() each time it executed a user > command, it can't save information and reuse it very easily--the > next command is really executed by a brand-new invocation of the > command interpreter. Disclaimer: I don't use VMS very often and I don't like it much. But: I do know that if you hit the <up arrow> key the shell gives you the previous command line. Repeat n-times and you get the nth previous command line. If it can do this, I can't believe it couldn't support multiple commands on one line. Speaking of fun command interpreters, Primos supports a command language that penalizes you for hitting <break> too many times (the exact number of times is set by your system administrator, I think). Also, you can construct an infinite recursive loop in the command processor that eventually terminates with "FATAL$ USER ENVIRONMENT REINITIALIZED" -- # Scott Schwartz # UUCP: ...{{seismo,ihnp4}!bpa, cbmvax!vu-vlsi, sun!liberty}!swatsun!schwartz # AT&T: (215)-328-8610 /* lab phone */
tihor@acf4.UUCP (05/20/87)
(1) There is no default language since it is not expecte that you will need to recompile the system. I use C for most of my own work, PL/I to maintain some existing systems, SPITBOL for quick awk like stuff, and Ada, Fortran, or Pascal for oddball programs I need to write quick depending on what theroutine in question will be doing. (2) Have you used the Boure Shell DEc sells? I am not a great fan or either bs or csh (although ksh is not bad) but have used all of the above on occasions. Of course we had to get the other command interpreters just like we have to buy the languages. Hopefully the P1003.n work will make that easier since we will just be able to specify the Posix package for VMS and get it.
mkhaw@vaxc.UUCP (05/20/87)
In article <1135@byzantium.swatsun.UUCP> schwartz@swatsun (Scott Schwartz) writes: ... >But: I do know that if you hit the <up arrow> key the shell gives you >the previous command line. Repeat n-times and you get the nth previous >command line. If it can do this, I can't believe it couldn't support This may have changed with more recent releases, but in VMS 4.2, there was a limit of 20 remembered commands. I don't see any relationship between DCL storing prior commands and whether or not it accepts multiple commands on one line. Mike Khaw -- internet: mkhaw@teknowledge-vaxc.arpa usenet: {hplabs|sun|ucbvax|decwrl|sri-unix}!mkhaw%teknowledge-vaxc.arpa USnail: Teknowledge Inc, 1850 Embarcadero Rd, POB 10119, Palo Alto, CA 94303
jfh@killer.UUCP (John Haugh) (05/20/87)
In article <672@bsu-cs.UUCP>, jbwaters@bsu-cs.UUCP (J. Brian Waters) writes: > In article <3583@jade.BERKELEY.EDU>, steven@pearl.berkeley.edu (Stephen the Greatest) writes: > .> Also, the primary language for VMS (as least I think) is FORTRAN while UNIX > .> is C. This does tells us something about the strengths of each operating > .> systems. Personally, I like BSD UNIX better. > .> > .> - Stephen Chung > > In the for what it is worth dept., VMS is primarly written in BLISS. While using VAX/VMS at the University of New Orleans I used to get a wide variety of tracebacks from the different utilities. Seems I remember alot of them were BLISS, but there also were alot of FORTRAN runtime messages. BLISS's sole claim to greatness seems to be that an lvalue must be an address, thus device_register = value stores the value at the address which is the value of device_register, not at the address of device register. You had to do something with dots to get what you wanted. I don't remember, but then I wonder if BLISS programmers remember either. - John. (jfh@killer.UUCP) Disclaimer - No disclaimer. Whatcha gonna do, sue me?
terryl@tekcrl.UUCP (05/20/87)
In article <12911@vaxc.ARPA> mkhaw@vaxc.UUCP (Michael Khaw) writes: >In article <1135@byzantium.swatsun.UUCP> schwartz@swatsun (Scott Schwartz) writes: >... >>But: I do know that if you hit the <up arrow> key the shell gives you >>the previous command line. Repeat n-times and you get the nth previous >>command line. If it can do this, I can't believe it couldn't support > >This may have changed with more recent releases, but in VMS 4.2, there was >a limit of 20 remembered commands. I don't see any relationship between >DCL storing prior commands and whether or not it accepts multiple commands >on one line. Definitely agree that one has absolutely no relation to the other... Pardon for my ignorance (I haven't had to use VMS since MANY, MANY moons ago, around version 1.6, me thinks), but isn't the reason for only one command per line is because (drum roll Anton, thanx) (NOTE: this is from VERY hazy memory) WHAT DO YOU USE FOR A COMMAND SEPARATOR???? After all, just to specify FILE names, all of these characters are already taken: : ; . * [ ] $ / plus all of the digits and letters (maybe _ also?) And to specify switches/arguments to commands, these characters are taken: ( , = ) + - / I rest my case!!! (Insert MANY (-: here)
wayne@fmsrl7.UUCP (Michael R. Wayne) (05/20/87)
After a coworker got very tired of listening to me grouse about
how terrible VMS is (I guess he had a hard time getting work done with all
the noise I was making), he wrote a csh simulator for VMS. Now, it is
VERY crude and somewhat fragile but it certainly helps me work on the
machine. What it does:
redirection < and >
multiple commands/line com1 ; com2
history with substitution (matches spaces too)
ls, cat
What it doesn't:
pipes (sigh)
Because of the ; being used as a seperator, you must ref version numbered
files like foo.bar.5 raterh than foo.bar;5. If there is interest, I could
try to post it (I'll have to call him first, he no longer works here).
--
Michael R. Wayne Voice: (313) 322-3986 | philabs \
Working at (but not employed by) Ford Motor Company | pyramid !fmsrl7!wayne
| ihnp4!mb2c / mkhaw@vaxc.ARPA (Michael Khaw) (05/21/87)
In article <888@fmsrl7.UUCP> wayne@fmsrl7.UUCP (Michael R. Wayne) writes: > > After a coworker got very tired of listening to me grouse about >how terrible VMS is (I guess he had a hard time getting work done with all >the noise I was making), he wrote a csh simulator for VMS. Now, it is Here's one vote for posting that code. If it's halfway decent, I'd use it rather than pay an arm an a leg for DECShell. (I know, DECShell has a lot of Unix-like utilities, but all I want is shell-like i/o redirection and multiple commands on 1 line). Mike Khaw -- internet: mkhaw@teknowledge-vaxc.arpa usenet: {hplabs|sun|ucbvax|decwrl|sri-unix}!mkhaw%teknowledge-vaxc.arpa USnail: Teknowledge Inc, 1850 Embarcadero Rd, POB 10119, Palo Alto, CA 94303
tim@brspyr1.BRS.Com (Tim Northrup) (05/21/87)
in article <888@fmsrl7.UUCP>, wayne@fmsrl7.UUCP (Michael R. Wayne) says: > > After a coworker got very tired of listening to me grouse about > how terrible VMS is (I guess he had a hard time getting work done with all > the noise I was making), he wrote a csh simulator for VMS. > > If there is interest, I could > try to post it (I'll have to call him first, he no longer works here). YES PLEASE!!! We work on a multitude of different UN*X systems here, along with VMS and some form of transition aid like this would be VERY helpful. -- And in this corner, hailing from `Parts Unknown', Tim "The Animal" Northrup Disclaimer: These opinions (if any) are MINE. That's right, MINE! Mine, Mine, Mine ... ALL MINE!
steven@pearl.berkeley.edu.UUCP (05/21/87)
In article <888@fmsrl7.UUCP> wayne@fmsrl7.UUCP (Michael R. Wayne) writes: > > After a coworker got very tired of listening to me grouse about >how terrible VMS is (I guess he had a hard time getting work done with all ... Here is another vote.
corwin@bsu-cs.UUCP (05/22/87)
In article <3583@jade.BERKELEY.EDU>, steven@pearl.berkeley.edu (Stephen the Greatest) writes: > In article <34ab0e42.8be4@apollo.uucp> jps@apollo.uucp (Jeffrey P. Snover) writes: > > > >>I know that bsd unix outperforms vms; I also know by > >>experience that vms interfaces (to programs and other > >>users) are quite bad. > > > > > >VMS interfaces "are quite bad" ? REALLY! I have worked > >with both UNIX and VMS for many years and whereas VMS > >does have its weakness, I don't think that any sentine > > > pretor) in VMS. Why can't anybody in DEC write something like C-Shell? > I think VMS is absolutely able to support a C-Shell-like command interface. > Also, the primary language for VMS (as least I think) is FORTRAN while UNIX > is C. This does tells us something about the strengths of each operating > systems. Personally, I like BSD UNIX better. > > - Stephen Chung I just finished an extensive paper on system management philsophy, and it basically compares and contrasts Unix with VMS in about as thorough a study as I could manager without writing a book. In my paper I show how each system was designed with very different goals in mind, and that those goals molded and shaped the respective OS's right down to the internals. I go on to show how there can be no real comparison of the two, since they are aimed at such different target markets and to some extent have such different features. The continual Unix vs. VMS battle (which is the subtitle for my paper) seems to be a bit foolish. The key words tt are used seem to be 'I like', and so it appears that a lot of what is being passed for objective data is in fact subjective opinion. For instance: DEC does market DEC/Shell for VMS, so it is an established fact that a Unix-like environment can be run on top of VMS. Another question is what is being criticized. If you are criticizing DCL say so; it is one thing to criticise the command language interpreter and another to belittle the operating system internals. VMS is a far more reliable system than Unix, and I am sure most Unix gurus sufficiently familiar with VMS will acknowledge this. On the other hand, both systems seem to be about equal in terms of security. Anyways, this is all in my paper, which will hopefully be published somewhere soon... My point is that trying to 'prove' that one OS is 'better' than another is engaging in a battle of wits with water pistols unless you set up strict criteria of comparison. I would enjoy seeing a real discussion of VMS vs. Unix get going here, replete with "But the VMS manual says X" and then "Ah, but in the Unix manual Dennis says..." and so on. The tossing about of unsubstantiated comments is neither productive nor fair to either operating system. Once you acknowledge that the design goals in each case were different, it begins to come clear that there can never really be a comparison of the two operating systems for that reason... Sorry somewhat acerbic. Hectic finals week for me. Apologies for any toes stepped on, etc... -- Paul "Corwin" Frommeyer "Experience is no substitute for competence." UUCP: {seismo,ihnp4}!{iuvax,pur-ee}!bsu-cs!corwin
corwin@bsu-cs.UUCP (05/22/87)
In article <667@bsu-cs.UUCP>, dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: > In article <3583@jade.BERKELEY.EDU> steven@pearl.berkeley.edu (Stephen the > Greatest [or so he claims]) says this about VAX/VMS: > > ...Also, I hate the shell (or command inter- > >pretor) in VMS. Why can't anybody in DEC write something like C-Shell? > >I think VMS is absolutely able to support a C-Shell-like command interface. > > VMS is not able to support a C-Shell-like command interface for a rather > important reason. The UNIX shell interface depends heavily on process > creation and many commands create several processes. > > VAX/VMS is extremely inefficient at creating new processes. When the > VMS command interpreter executes a user program, it does not create a > new process, but simply does the equivalent of a UNIX exec() system > call. Thus the current invocation of the command interpreter > effectively dies and is replaced by the user program. (How it regains > control after the user program terminates is a long, long story that > I don't fully understand.) > I'm into hazy territory here (anyone from Digital feel free to jump my case if I go astray...), but I believe the problem lies not with VMS but with the DCL interpreter. When DCL spawns, it usually hauls it's "environment" (used loosely here; not like Unix) along with it. This means that the new process has to get a copy of the global symbol table, the logical name table, etc. There seems (to me) to be no reason for a process creation slowdown in the OS. The $CREPRC system service is in main memory; so are the data structures it manipulates. Unless the process is swapped out immediately after creation, a new process sould run with little delay. It's the way DCL passes it's environment that slows things down. That and the loading of a new program image from disk, but then that's an I/O problem more than an OS difficulty. I do know Digital markets DEC/Shell, which is supposed to be like Bourne shell. I don't know the speeds on it, but it is supposed to spawn processes. As far as the image exit handler return path, yeah, that's messy. If my technical info is way off base, let me know. -- Paul "Corwin" Frommeyer "Experience is no substitute for competence." UUCP: {seismo,ihnp4}!{iuvax,pur-ee}!bsu-cs!corwin
david@elroy.Jpl.Nasa.Gov (David Robinson) (05/23/87)
In article <688@bsu-cs.UUCP>, corwin@bsu-cs.UUCP (Paul Frommeyer) writes: > > I just finished an extensive paper on system management philsophy, and > it basically compares and contrasts Unix with VMS in about as thorough a > study as I could manager without writing a book. In my paper I show how > each system was designed with very different goals in mind, and that > those goals molded and shaped the respective OS's right down to the > internals. I go on to show how there can be no real comparison of the two, > since they are aimed at such different target markets and to some extent > have such different features. > > The continual Unix vs. VMS battle (which is the subtitle for my paper) > seems to be a bit foolish. The key words tt are used seem to be 'I like', > and so it appears that a lot of what is being passed for objective data > is in fact subjective opinion. I agree 100% with your analysis of of the OS battles. You should pick an OS for what you need done, not a religious reason. The same goes for programming languages. > (...) VMS is a far more reliable > system than Unix, and I am sure most Unix gurus sufficiently familiar with > VMS will acknowledge this. I would not call myself a "guru" but I have used both VMS and UNIX quite a bit and I can't agree with you on this point. It is a common argument against UNIX and is not valid. The reliablity of a system is more closely related to the quality of the vendor who sells it. I have found that the Sun systems that I use crash a *LOT* less often than the VMS systems (especially versions ending in an even number ). There are a few UNIX vendors out there who are very good at support and have very clean systems, on the other hand there are a few really bad ones too. People who get BSD UNIX direct from Berkeley and don't hire an adequate system manager to support it get what they deserve, a poorly supported OS. VMS tends to have more Bugs just because of the shear size of the OS and utilities, VMS VX.[0-1] is usually quite buggy and you are best to wait until it stablizes before upgrading. I have found each has its advantages and disadvantages depending on your application but you can do almost anything in either if you try hard enough. > -- > Paul "Corwin" Frommeyer "Experience is no substitute for competence." -- David Robinson elroy!david@csvax.caltech.edu ARPA david@elroy.jpl.nasa.gov (new) seismo!cit-vax!elroy!david UUCP Disclaimer: No one listens to me anyway!
mouse@mcgill-vision.UUCP (der Mouse) (05/31/87)
>> Why can't anybody in DEC write something like C-Shell? They have. (But it runs under Ultrix.... :-) Really, though, there *is* a UNIX-like shell for VMS. Don't ask me anything more about it though, I'm sure your local DEC salescritter will be glad to tell you all about it. > [can't be done, here's why] > VAX/VMS is extremely inefficient at creating new processes. When the > VMS command interpreter executes a user program, it does not create a > new process, but simply does the equivalent of a UNIX exec() system > call. Thus the current invocation of the command interpreter > effectively dies and is replaced by the user program. (How it > regains control after the user program terminates is a long, long > story that I don't fully understand.) The CLI doesn't die. Memory on a VAX is partitioned into four regions, according to the top two bits of the virtual address: 0x00000000 - 0x3fffffff P0 space 0x40000000 - 0x7fffffff P1 space 0x80000000 - 0xbfffffff System space 0xc0000000 - 0xffffffff Reserved space The first two are per-process (a context switch switches them); all processes share the same system space (though for a normal operating system, a normal user program can't access much, if any, of it). Under VMS, the CLI lives in P1 space. When a user program is run, it is run in P0 space; it uses P1 space only for the stack. The CLI is careful to set the stack up well below the memory used by the CLI itself. Thus, the CLI is still around when the user program exits. It has to be - how do you imagine DCL keeps symbols around? der Mouse (mouse@mcgill-vision.uucp)
iwm@doc.ic.ac.uk (Ian W Moor) (05/31/87)
In article <667@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: >In article <3583@jade.BERKELEY.EDU> steven@pearl.berkeley.edu (Stephen the >Greatest [or so he claims]) says this about VAX/VMS: >VMS is not able to support a C-Shell-like command interface for a rather >important reason. The UNIX shell interface depends heavily on process >creation. ... When the >VMS command interpreter executes a user program, it does not create a >new process, but simply does the equivalent of a UNIX exec() system >call. Thus the current invocation of the command interpreter >effectively dies and is replaced by the user program. (How it regains >control after the user program terminates is a long, long story that >I don't fully understand.) >The above does not prevent DEC from providing a structured shell >programming language. However, the command language (modestly named >DEC Comamnd Language) appears to have a batch environment as its design >basis, and has very little "memory" of past statements executed. In a >batch enviroment, where each control card is separately interpreted, it >is difficult to provide control structures such as >if..then..else...endif, while and for loops, etc. > .... >But since the command >interpreter effectively does an exec() each time it executed a user >command, it can't save information and reuse it very easily--the >next command is really executed by a brand-new invocation of the >command interpreter. From a quick reading of part of the VMS internals book, DCL is an interpreter with its variables in protected memory (Executive mode I think) and its code in shared system memory. Running a program involves reading code into memory and CALLing it, there is no way that the command interpreter has to restart. DCL lacks proper structuring facilities, from VMS 4.4 it has IF THEN and GOSUB RETURN, but nothing more; I consider this a serious design error in DCL and not VMS though. It does seem to be better than shell at string handling and file io however. Process creation is slower than Unix but not excessively spawning a sub process from an editor or debugger is a matter of a second or so. It seems that in many cases Unix uses processes as an implementation technique because they are cheap, so straight ports of code to VMS run slowly, but a little work speeds them up: MMS (DEC's Make clone) creates a single subprocess and feeds commands commands to it rather than creating a process per command. -- 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.
iwm@doc.ic.ac.uk (Ian W Moor) (05/31/87)
In article <5840@eddie.MIT.EDU> jbs@eddie.MIT.EDU (Jeff Siegal) writes: >In article <3583@jade.BERKELEY.EDU> steven@pearl.berkeley.edu (Stephen the Greatest) writes: >>Also, the primary language for VMS (as least I think) is FORTRAN while UNIX >>is C. > >Actually, the "primary language" (whatever that means) is probably >Assembler (MACRO-32), since that comes with every /VMS system, while >Fortran is a separate product that costs significant extra $. Judging by programs submitted to DECUS and comp.os.vms the prime language seems to be Fortran, though DEC Fortran has enough extensions to make it useable :- IF THEN ELSE ENDIF, record structures ... If you mean the implementation language for VMS, most of it is BLISS, which is about the same level as C though the code that is generated is better. -- 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.
gwyn@brl-smoke.ARPA (Doug Gwyn ) (06/02/87)
In article <688@bsu-cs.UUCP> corwin@bsu-cs.UUCP (Paul Frommeyer) writes: >... I would enjoy seeing a real discussion of VMS vs. Unix get going here, ... Please don't! This newsgroup/mailing list is for questions about UNIX. UNIX runs on nearly everything; VMS runs only on VAXes. Please conduct VAX-specific arguments in VAX-specific newsgroups, e.g. comp.sys.vax/INFO-VAX, in order to reach just those people who care about the issue. I believe there is also a newsgroup for generic OS discussion. Let's not clutter this information service with the same old irrelevant debates over and over.
kuo@skatter.UUCP (06/08/87)
In article <448@ivax.doc.ic.ac.uk>, iwm@doc.ic.ac.uk (Ian W Moor) writes: > [deleted] > > Judging by programs submitted to DECUS and comp.os.vms the prime language > seems to be Fortran, though DEC Fortran has enough extensions to make it ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > useable :- IF THEN ELSE ENDIF, record structures ... ^^^^^^^^^^^^^^^^^^ > If you mean the implementation language for VMS, most of it is BLISS, which > is about the same level as C though the code that is generated is better. > > [deleted] Allow me to point out these (underlined with ^^) are ANSI FORTRAN 77 standards, not DEC VMS FORTRAN extensions! And rumours has it that the new ANSI FORTRAN 80X (88?) will make MOST of the VMS FORTRAN "extensions" ANSI standard, plus other goodies (esp. in vector operations and recurrusiveness). ... Peter/ ------------------------------------------------------------------------------- Peter Kuo | Bitnet (VMS) : KUO@SASK Accelerator Laboratory | (a.k.a. The Beam Warehouse) | uucp (Unix) : !alberta\ Univ. of Saskatchewan | !ihnp4 -- !sask!skatter!kuo Saskatoon, Saskatchewan | !utcsri / CANADA S7N 0W0 | (Earth) | Ma Bell : (306) 966-6059 Disclaimer: I don't know what I am saying, so don't quote me on anything! And I only speak for myself.