Re: Fiewalls on VMS

Michael Kraemer wrote:

In article <4A42DC18.48EAAECC@xxxxxxxxxxxxxxxx>, David J Dachtera
<djesys.no@xxxxxxxxxxxxxxxx> writes:
Michael Kraemer wrote:

David J Dachtera schrieb:


Now? That question answers itself, does it not?

No. Of course hardware got faster,
but also the amount of data to be shared.
And again, what has this to do
with the way data are shared in VMS vs Unix ?

VMS = shared everything

UN*X = shared nothing - needs add-ons like NFS, as you noted.

Oh come on, don't get ridiculous.
NFS is an integral part of Unix systems for about two decades,

That's like saying DECnet is an "integral part of" VMS just because it's
no longer installed as a SIP, it's an install option in the base kit and
is not required for normal cluster functioin.

if not longer, just as TCP/IP, sockets, X11, etc.
With the same right one could call VMS clusters an add-on
because it was added several versions later than 1.0 (at least IIRC).

One major difference is that SCS runs quite happily with no other
network stack loaded. Can't say the same for NFS since that's an IP
sub-protocol with TCP layered into the mix.

On Unix, I can share printers, filesystems, apps, data,
just about everything which is important to me.

Really? How do you that? (Remember again that we're talking 100's of
printers, 1000's of TPS and tens of thousands of I/Os per second.)

Quite a bit more than "nothing".


...and no, it's not "a single issue (I am) trying to solve." It's the
whole system: tiers 2 and 3 of a three-tiered, very high transaction
volume system (electronic health record).

To me, not being a DBA type, it appears to be a single issue,

Nuff said.

[snip]

What kind of outages were they seeing?

It wasn't only "they", it was "us" users
who suffered. Typically, for no apparent reason,
the whole cluster thingy went down.
Black screen of death, everything rebooting.

Did anyone ever mention "CLUEXIT"?

One had to login, restore all desktop apps that were running,
restart/repeat aborted interactive stuff etc.
For a particular user,
it could have taken hours until he could proceed with normal work.
If it happened early friday afternoon, one could as well leave
for the weekend.
It certainly didn't happen on a weekly basis,
but often enough to be annoying, at least during the few
years I had to use VMS on a regular basis.

I don't know if they ever found the real reason
(I switched to greener pastures), but I suspect
the network to be clustering's Achilles heel,
rather than hardware or plain OS failures,
because *all* boxes went down, whereas non-VMS
on the same network was not (or less) affected, AFAICR.
I never observed that kind of blackout on Unix boxes.

Well, scant details; however, those symptoms are consistent with cluster
communications issues. Had the network people been trained on networking
and not just on TCP/IP, it could probably have been resolved without
anything as draconian as a platform migration.

And anticipating the usual objections
("it's history", "too old", "should have upgraded", "should have done
this or that"): those are not the point.
It's simply that at that point in time the grass was much greener
on the Unix side than on the VMS side. And it stayed that way.

Hhhmmm... Sounds like they may have been trying fit the clustering
"round peg" into an application's "square hole".

I don't know what should be "round pegs" or "square holes"
in this context, the described cluster setup wasn't
unusual in technical computing at that time,
in fact it was probably more common than pure DB installations.
And the people in charge weren't dummies
but had close to ten years VMS experience
and would rather have worked extra night shifts than to
admit that their cluster runs worse than Unix.
So it must have been something not easily to be fixed.

Indeed - likely network (cluster communications) issues which, if TCP/IP
is all one has been trained on, can be a bit like sending construction
electricians to diagnose and repair a diesel-electromotive unit with a
failed prime mover.

D.J.D.
.

Relevant Pages

  • Re: Fiewalls on VMS
    ... with the way data are shared in VMS vs Unix? ... NFS is an integral part of Unix systems for about two decades, ... Some of the most reliable hardware of the day. ... the whole cluster thingy went down. ...
    (comp.os.vms)
  • RE: Routable Protocol for Clustering
    ... >> The only limitations to the Proprietary VMS cluster are ... VMS clustering ... Our configuration uses the same technology, except our network is over 360 ... >> to enhance our business process. ...
    (comp.os.vms)
  • Re: Fiewalls on VMS
    ... be it UNIX or mainframe or whatever. ... but for whatever reason it sounds like their cluster availability was ... why bother with VMS? ... image single management domain UNIX clustering in common use, ...
    (comp.os.vms)
  • Re: COV Sponsors
    ... > And, of course, a good many clusters don't need a database at all, ... > a cluster file system. ... >> The modern programming methods bypass the need for VMS style ... An application that can run in a Unix cluster has no ...
    (comp.os.vms)
  • Re: Enquiry regarding Linux in Mission Critical situation
    ... UNIX is the bastard descendent of Multics, a VERY mainframe system. ... VMS is the basis for Windows NT. ... > How about an NT cluster, ...
    (comp.os.linux.security)