Re: vms versus solaris
From: Dave Froble (davef_at_tsoft-inc.com)
Date: Tue, 18 Jan 2005 13:39:54 -0500
Bill Gunshannon wrote:
> In article <41EC88AA.firstname.lastname@example.org>,
> Dave Froble <email@example.com> writes:
>>Bill Gunshannon wrote:
>>>>>Wether the user wants it to or not.
>>>>No, can't say that. Using QIO you have access to files without any of the RMS
>>>>overhead. You can implement whatever type of file handling you wish, and have
>>>>the DLM to easily implement whatever type of locking you wish.
>>>But which is the default when I say "OPEN" in Pascal or some other
>>>language? Yes, you can get around RMS, but VMS starts with the
>>>everything including the kitchen sink. Unix starts with the least
>>>and lets the user add on additional requirements. Different
>>>approaches to the same problem caused by the difference in the
>>>underlying paradigm of the OS. Neither one is better, just
>>When you say "OPEN" in Pascal, you're now talking about what a language and
>>compiler offer, not what the OS offers. What happens when you open a VMS
>>channel to a file from Pascal? You can now do I/O at the QIO level. What's
> Actually, I'm talking about what a Pascal Programmer is going to put
> in his code. QIO isn't Pascal. Just for grins, tell me which is faster.
> Using QIO or using the default IO provided by Pascal? I am pretty sure
> I already know the answer to that. And the result is everybody gets
> overhead even when it really buys them nothing. Unix philosophy is
> the other way around. If you want more, use it, but everybody (probably
> the majority) don't really need it.
I consider myself a BASIC programmer since I do more of that than anything else.
While there is a bunch of Macro-32 stuff, I don't use it enough to claim
proficiency. I think you have to do it all the time to be proficient. As for
the Basic stuff, I could post multiple examples where I ASSIGN a VMS channel and
perform QIO operations. I can't see why the same couldn't be done from Pascal
>>>>>There are alternatives that provide records and thus record locking.
>>>>Can you be a bit more definitive about "thus record locking"? Care to look at
>>>>it in a multi-system configuration? With the exception of some IBM software,
>>>>I'm not aware of anything that can be considered in the same catagory as the VMS
>>>First, in order to have useful "record locking" you have to have something
>>>that handles data as records. It has already been stated (and accepted by
>>>the Unix camp) that the default file system is just a stream of bytes.
>>So Ok, from within a program on Unix, I implement code that treats the file as
>>records, calculating the record offset and bytecount and such. Now, how do I
>>take out a lock on the string of bytes I am accessing that will be respected by
>>cooperating programs? On VMS I can very easily use the DLM.
> If you are implementing a system, it's up to you. If your using a system
> someone else implemented, use theirs. Obviuosly, Unix can't provide a
> record locking mechanism for a system it is unaware of. And if the
> programs are "cooperating" it seems a trivial problem. The real problem
> becomes locking out that program that doesn't want to cooperate. I think
> that is what things like DLM do.
Nope! Like any type of locking, it's a cooperative thing. There was a thread a
while back that discussed locks at the ACP level. I'm pretty sure that I can
assign a channel and read from a file regardless of what other activity is
occurring, so without cooperation, there is no effective locking.
What's nice about the DLM is that it's not just something for files. A lock can
be taken out for any resource name, and all tasks that will respect that lock
can coordinate their activity.
>>>As for multi-system configurations, I freely admit that no Unix I am
>>>aware of can do what VMS does in that arena. However, because everybody
>>>isn't flocking to VMS from Unix, apparently it isn't really that important.
>>Maybe Unix users have given up, or have devised workarounds, or don't even know
>>that such is possible. All three possibilities make their work harder, and less
> Hardly. There are just a lot of things that have come out of computing
> research that actually affect a lot less people than you think. of course,
> another one of the advantages to unix is that if you want something and
> no one else does you are free (and it is technically possible) to do it
> yourself because there are unixes available with the entire source and
> the legal right to re-engineer them. Interestingly enough, you don't find
> that happening very often.
>>>But, instead of trying to point out all these non-existant Unix short-
>>>comings maybe it wold be better if you just pointed out what VMS can
>>>do that Unix can't. That way you win and people who know the truth
>>>about Unix won't laugh behind your back after you have left the room
>>>from a loosing sales presentation. :-)
>>Distributed Lock Manager
> There's one. (Although there actually is a DLM for Unix. It's just that
> most unix people haven't really found much use for it yet.)
>>Robust development environment.
> How is it more robust than the ones available under unix?
Don't know. I don't use Unix. I do know that I can use many different
languages on VMS, including mixing together modules written in different
languages in the same application. The common calling standard on VMS is
something I should have included in the list. Don't know if Unix has the same.
However, the only language on VMS that can cause some problems is C. Gotta be
real careful when calling a C routine, or when calling from C.
> Dykstra would say that was a strike against VMS.
Another bigot, like me?
> And why is it any
> better than the BASIC(s) available under unix?
For me, because I have a hugh amount of code, which probably wouldn't work
without some conversion on another system. Admittedly, that reason is specific
to me and other users of VAX/DEC BASIC, but there are more than a few, and it's
a very big issue to us.
>>Clustering, as it was originally defined, shared everything, not fallover
> Now you have two. But this one only affects a small handfull of users.
Are you saying that because VMS has a small market share? If not, then justify
your claim. It's this capability that allows VMS to scale to the job, and
adjust as job requirements change, all transparent to the applications.
Possibly your "small handful" actually do much more work than a very large
number of Unix users?
> What is the advantage of DECnet over other networking protocols? There
> are lots of disadvantages. Oh yeah, that has been available for unix
> since the Ultrix days and while I have even used it, unless you are
> also running VMS (or PDP-11's :-) it really hasn't much use in the unix
Ah, I'd forgotten that there has been implementations of DECnet for many other
operating systems. Got me on that one. But, DECnet can be much more secure
than TCP/IP. That might be of use to the Unix world.
>>Since I don't know Unix, some of the following may not be VMS only:
> If this is Systemwide Logicals, unix can do that, but not as gracefully
> as VMS.
Shared sections of memory.
>>Access to system calls outside of C
> ?? Outside in what way? Any language can call any library. If you
> mean from a shell, I've never seen it done and because of the nature
> of the unix system calls I am not sure it would even make sense.
Sometime in the past there was a thread on something similar to this. I asked
how to perform some task, and the replies indicated that the only access was
through the use of a C library routine. Can't remember the details.
> Got them. Just don't call them the same thing.
> Aren't they really the same as Logicals? (I really don't know the
No, not the same thing.
> Not sure of the real nature of VMS "Mailboxes". I get my email in a
> "mailbox", but VMS seems to have a different meaning. I think this
> is likely the same pty's or some combination of other methods of IPC.
A VMS mailbox is a inter process communication device. It can be sync or async.
>>>>>When Unix users need this feature they use it. But more oftne than
>>>>>not, they don't need it. Neither do they need the overhead such
>>>>>systems bring with them.
>>How about, they don't use some features because they don't have them available?
> If they really needed them, someone would implement them.
The problem here is that probably many people each do a custom implementation,
which can be significant work. With the capability already in VMS, the need to
implement is gone. It's like 2 C libraries, one with minimal support, and one
with a robust selection of capabilities. Which would you rather use?
> Heck, Linus
> Torvalds implemented another whole unix-like system because of his
> warped sense that it was "needed". And the developers flocked to
> him to expand it. Do you really think that if there wa anything that
> was really seen as important that no one would implement it?
>>>>As mentioned before, using the QIO interface, VMS can also do low overhead I/O.
>>>> The difference is with Unix, usually one must acquire additional capability,
>>>>with associated costs, while the capability is part of VMS.
>>>Associated costs? How much does Postgres cost? Large amounts of
>>>Unix software is available for the taking. Again, difference in
>>>philosophy. I will put any package my users need (within reason,
>>>you won't find Doom) on our Unix servers. The people who run the
>>>VMS system will not even put up stuff from the Freeware CD.
>>What some people will put on Unix, and what others will put on VMS, doesn't seem
>>to have anything to do with a discussion on OS features.
> The example was merely meant to show that the biggest difference between
> VMS and unix is philosophical between the two userbases. Which is why
> it always seems to be a religous war rather than a technical discussion.
> PS. Hope it's warmer in your corner of the state than it is in mine!!
Down to 3 last night. :-(