[Info-vax] Anyone interested in another public access system

David J Dachtera djesys.no at spam.comcast.net
Sat Apr 11 19:46:05 EDT 2009


Bill Gunshannon wrote:
> 
> In article <49DF7A1A.EB9E7656 at spam.comcast.net>,
>         David J Dachtera <djesys.no at spam.comcast.net> writes:
> > Bill Gunshannon wrote:
> >>
> >> In article <49DD40D5.3F95722D at spam.comcast.net>,
> >>         David J Dachtera <djesys.no at spam.comcast.net> writes:
> >> > Bill Gunshannon wrote:
> >> >>
> >> >> In article <49D6D457.A96B7D25 at spam.comcast.net>,
> >> >>         David J Dachtera <djesys.no at spam.comcast.net> writes:
> >> >> > [snip]
> >> >> > Need I go on?
> >> >>
> >> >> No, when your measure of modern computing is whatever is VMS-style
> >> >> I guess anything that isn't VMS is deficient.
> >> >
> >> > What would you prefer as a "gold standard" against which to measure?
> >>
> >> I'm not arguing for any standard.  I am merely pointing out that if you
> >> make VMS the standard, then any OS other than VMS is going to be rather
> >> deficient because VMS is VMS and every other OS is not.
> >
> > ...and, of course, the counter-argument could be made about <mumble>
> > features not being available in non-<mumble>.
> 
> Not having something that no one wants is not a shortcoming.

See below for the discussion of "no one wants".

> >
> >> That's kind of
> >> like saying the standard for good literature is what is written in
> >> english.
> >
> > Not a valid comparison. It might be for programming language vs.
> > programming language, but not o.s. vs. o.s.
> 
> Why not?  You are using an irrelevant standard for comparison, just
> like using language as a standard for literature using VMS as a
> "standard" for what an OS provides is just plain silly. 

Well, if you want to REALLY get technical on that, translating The
Qur'an from Arabic to any other language is considered to be a source
loss of the scripture's true meaning.

So, in some cases, yes - language IS considered to "define" literature
at a fundamental level.

But back to the point, no it iS *NOT* a valid comparison as regards VMS
vs. alternatives any more than make-model is valid comparison of, for
example, motorcycle vs. sedan, mini-van vs. tour bus, wood-frame house
vs. a limestone castle, or the like. Who built it and/or design purpose
is relevant to a discussion of the components used ot build it.

For another example, carpenters have little use for plumbing tools, and
vice-versa, yet both consider their tool sets essential to their trade.
A carpenter could go his whole career never knowing what a three-wheel
pipe cutter is or even that such a tool exists, while plumber would very
likely prefer to have one in his toolset, even if he/she can easily do
without.

> Actually,
> there is a standard for what an OS should provide.  It's called POSIX.
> Which OS come closer?

None. POSIX is modelled after commonly used features originating in UN*X
and to some extent DOS/Windows in so far as the feature sets overlap,
but is intended to be o.s. agnostic. That's why a standards set, and not
o.s. architecture specification.

> >
> > A better comparison might be two-seater vs. a mini-bus or a ranch vs.
> > two-story home. Different feature sets underlying the upper-layers.
> 
> Actually, those are all equal comparisons.  I am quite certain that a
> person who drives a "two-seater" does not consider it somehow defficient
> cause it doesn't have the features of a mini-bus.  And, being the owner
> and driver of a Mazda Miata and an MGB, I speak from experience.

Miata and MBG are both two-seaters. How many of the kids, aunts, uncles,
cousins, etc. can you take in either one when heading out to the family
holiday dinner, or whatever occasion may result in your being called
upon to "haul" the family?

You may go your whole life never needing to do so ("you don't know that
you need it"). However, should the need eventually arise, you may find
your two-seater not quite up to the task, especially in inclement
weather when you cannot resort to an illegal seating arrangement.

> >
> >> By that standard ther eis no good german or french literature.
> >> I think the world would disagree.  And, as can be seen by example, the
> >> industry has rejected VMS as a standard for which all computing must
> >> strive.
> >
> > Well, actually no, it hasn't. Over-generalization - invalid asssumption.
> > You can't reject what you've never known about.
> 
> Are you saying that the industry never knew about VMS? 

The above answers that question, but I'll spell it out for you, anyway:

"the industry"? Show me where I said that.

A large cross-section of "the industry"? Not THAT big an over-statement
when substituted for the contextual "you've" in the foregoing.

> Boy are you
> mistaken.  There was a time when the names VAX and VMS were guarenteed
> proposal wins even when the competition won all the benchmarks.  And,
> I also learned that through direct, first-person experience!!  There was
> a time when VMS was as common in academia as Unix was.  That was definitely
> the case when I got her at the University of Scranton.  And when I was
> at West Point (which is much more a college campus than an Army base)
> the Computer Science Departement was a VAX/VMS shop.  We had Unix on
> the administrative side years before it started showing up on the academic
> side.  No, the IT industry was well aware of VMS before it rejected it.

Well, this is *VERY* *IMPORTANT* to understand, so make no mistake about
this:

"the industry" did not "reject" VMS. "the industry" was deliberately and
intentionally mislead by HP and its predecessor(s). 

Most recently, HP manegement went out to the ISVs to "preach" IA64. Oh,
yeah - they preached IA64, alright, but they preached UX on IA64, not
VMS. The ISVs read that as "VMS is EOL". (Direct witness from two of the
major healthcare ISVs on that one, so again, make no mistake. Search my
posts from the last 12 months or so, and you can easily find which two
vendors I refer to here.)

In my mind, that does not constitute "rejection". To me, that
constitutes following what the ISVs perceived as the vendor's lead (how
many times have we heard/read it said that "perception is reality"?).

> >
> > See http://www.merriam-webster.com/dictionary/marketing
> >
> >> > [snip]
> >> > It Depends. Define "success".
> >>
> >> How do you define it?  Market share?   Annual profits?  Number of systems?
> >> Number of Users?  Industry familiarity?
> >
> > Yes.
> >
> >> Where exactly does VMS exceed
> 
> Based on your answer above, why didn't you answer this one?

I did (Non-rhetorical answer!)

> 
> >> Unix (or just about any other major OS today) other than in meeting the VMS
> >> standard?
> >
> > Feature richness (VMS) vs. being feature-impoverished (UN*X, DOS,
> > Windows, etc.).
> 
> Back to that argument.  An OS is not "feature-impoverished" because it
> doesn't offer features that its user base is not interested in. 

It depends.

> You
> are aware of the history of Unix, aren't you? 

Painfully!

> Features are added all
> the time.  Journaling File Systems, Software RAID, IPSEC, IPv6.  None
> of this was in the original Unix.  But as the users decided they needed
> it, it was added. 

Like it or else, we're becoming - or already are - users of UN*X. We
needed RMS, DCL, Shared-Everything Clustering, Distributed Lock
Management, etc. on VMS, and we still need them. We just learn to make
do without because they're missing from UN*X.

Because we can make do without something does not mean we don't need it,
it just means we're worthy of our salary! (...and then some!)

> And should the users ever decide they really need
> some of the stuff that VMS has, it, too, will be added.  But not having
> capabilities no one wants is not a shortcoming.
> 
> >
> >> >
> >> >> How many times do you need to be told that Unix is adaptable enough that
> >> >> pretty much any of the things you mentioned could have been (and still
> >> >> could be) added except that Unix users don't see them as something to
> >> >> be bothered about.
> >> >
> >> > Probably until they actually come about. Are you volunteering?
> >>
> >> Why would I?  Like other Unix users I don't see a need for most of this
> >> stuff so why invest time and effort delivering a product no one, appaerntly,
> >> need and no one wants.  Make more profit selling refrigerators to eskimos.
> >
> > See http://www.merriam-webster.com/dictionary/marketing
> 
> What does that have to do with anything? 

See the above.

> Are you saying we should market
> features no one wants

Correction: "no one" knows that they need "it" (to avoid the tons of
kludges they may have already developed or are still tryting to perfact
to make up for, for example, the lack of RMS, the lack of shared disk
resoirces with distributed lock management (not available outside of
Oracle, for example), and so on.

How can you "not want" something if you don't know that it exists, or
don't know that it can help you avoid re-inventing so many wheels?

C-ISAM and B-tree were not just kludges whipped up by a user to fill a
local need. 

> so that someone will add them to Unix?  Seems to me
> that it makes more sense to just wait until someone actually needs them.

They already need them. If the need for something never existed, DEC
wouldn't have invented it, and then propagated it forward into VMS.

> >
> > Running joke about my brother-in-law (great b.s.-er): He could sell ice
> > cubes to an eskimo for the eskimo's last dollar, and the eskimo would
> > leave thanking him for it.
> 
> Old joke, don't see the point in this context except as stated above.

The context is there - you may need to open your paradigm a bit more to
allow yourself to see it.

> >
> >> >
> >> >> >
> >> >> > I've no way to know whether there is any hope of ever getting any new
> >> >> > blood in OpenVMS engineering, but I'm hoping someone, somewhere, perhaps
> >> >> > in VMS V10.0-1 will solve the "fork()" problem and in doing so solve
> >> >> > many of the incompatibilities between UN*X and VMS, perhaps even merge
> >> >> > UN*X and VMS into something that brings the best of both worlds to EDP.
> >> >>
> >> >> Personally, I don't think the fork() problem will ever be solved.  I
> >> >> think there is just too much difference at a very low level to make it
> >> >> possible.
> >> >
> >> > Oh, I'm sure it could be done, just not in the ways one might
> >> > traditionally think from either a UN*X or VMS point of view.
> >>
> >> If you don't do it the wya Unix does it then is isn't a Unix compatable
> >> fork() and accomplishes nothing.
> >
> > It Depends. If looks like a fork, acts like a fork and provides the same
> > functionality as a fork, then its a _ _ _ _ (fill in the blank).
> 
> Isn't that what I said?  If it does do the same thing as Unix fork() then
> it it would be "a Unix compatable fork()".

Keyword: "compatible" (not "identical")

> >
> > Why would the upper layer software care what happens "under the hood" of
> > SYS$FORK(), it is existed?
> 
> If it did the same as a Unix fork(), it wouldn't.  But, I believe the
> show-stopper is that it can't. 

Again, it depends. If the user code THINKS it achieved a UN*X-like fork,
and can manipulate the resulting elements as if it had, does it make a
difference whether the machinations inside the kernel were identical to
UN*X or not? (they likely would not be)

> I seem to recall that copying all the
> open file descriptors was one of the things that VMS couldn't do.  If
> I am remembering right, that's a show-stopper as I can show you at
> least one program right now for which that capability is an explicit
> requirement.

...until someone finds a way around it. Same as UN*X? Probably not. Same
end result? That's all that matters.

> >
> > [snip]
> > Rather like comparing a wrench to channel-locks or a vise-grip: - its a
> > question of the right tool for the job.
> 
> No arguemnt from me there.  But, sadly, there seems to be less and less
> jobs where people see VMS as the right tool.  With all its supposed
> advantages, its shortcomings compared to other OSes seem to be really
> holding it back.

If you need a tool that won't round-over the flats on a nut/bolt head,
but your hand is not strong enough to hold a channel-lock tight enough,
and you've never heard of a "vise-grip" (which is trade name for a brand
of locking plier, not an actual type of tool), then what's the right
tool for the job? It's the tool you don't have and don't know about, is
it not? You still want/need it, you just don't know about it.

D.J.D.



More information about the Info-vax mailing list