[Info-vax] VMS Forever?

[Richard Maher]

Hi Roland,

Said to hear what Verizon are doing. The good news is it has every chance of
failing, if not functionally, then certainly performance wize. (From the
background you provoded I would've thought they would've balked at the cost
of the rewrite already.)

>>>>>>>>>>>>>>>>>>>>
MQ Series and a host of other communications
products can already provide guarranteed message delivery, which has
absolutely nothing to do with 2-phase-commit.
<<<<<<<<<<<<<<<<<<<<

But it was just that store-and-forward technology that HP/VMS' IMM team used
to justify sacking Jim Johnston and Alan Potter (and who knows how many
others), the destruction of DECdtm, and then the promotion and eternal
funding of RTR. RTR was subsequently bundled with VMS so we couldn't see how
few people were using it or were about to drop it. And now VMS is paying for
it to be ported to Linux 'cos Captn RTR and his syphilitic hoard of
cutthroats can see there's not much left to plunder on VMS :-(

Jim still responds occasionally at that living DTC: -
http://social.msdn.microsoft.com/forums/en-US/windowstransactionsprogramming/threads/

Anyway, I hope you're right about the dificulties of implementing such a
beast on *nix. (I had feared Oracle's Distributed Lock Manager had the
concept of system owned locks that could survive process termination)

Cheers Richard Maher

"yyyc186" <yyyc186 at hughes.net> wrote in message
news:1ff8f08f-e801-4a36-949c-24cf23e7bf10 at e5g2000vbe.googlegroups.com...
On Mar 30, 5:52 pm, "Richard Maher" <maher... at hotspamnotmail.com>
wrote:
>
> Does anyone know the reason/justification for the move? Was it really HP
> running down VMS to a prime customer? Where was VMS Management during this
> phase - still counting their "Formidable" bonuses? Why don't they get out
> there and fight?
>

HP has been pushing them hard for a while.  The final straw was when
Verizon couldn't find any more illegal aliens to work for them with
VMS.  They are no migrating to a platform which will not work in their
environment, but comes with an ample supply homeland security risks
willing to work for nothing and live in NJ.  They've been posting
OpenVMS contracts for years offering $40/hr for people with 10-15
years experience.  Naturally, the only takers were those with severe
background check issues or dramatic visa problems.  Now they can't
even get those.  Fear not, they have been posting the HP/UX contracts
everywhere and are offering a whopping $30/hr for 10-15 years
experience.

Don't take my word for it, check the contract openings.  Some of them
actually are ethical enough to post the billing rate so they don't
have to waste any time answering the phone or email.

No Richard, there is no DECdtm equivelant on HP/UX.  Tuxedo is a
bigger joke than the Denver Colorado bagage handling system.  It
wouldn't matter.  If you read the contract openings carefully, you
will see that Verizon is trying to roll-their-own 2-phase-commit using
raw TCP/IP services.  MQ Series and a host of other communications
products can already provide guarranteed message delivery, which has
absolutely nothing to do with 2-phase-commit.  DECdtm (especially when
used with ACMS) ensured the ___transaction___ processing that message
executed.  If the system crashed while processing, DECdtm and ACMS
started processing that very same message again when the system came
back up and completed doing the required rollbacks.  There is
absolutely nothing on HP/UX which can do this.  There is not even the
wet-dream of a product in the future which can do it.  You cannot use
any OS which is loyal enough to the Unix heritage to be called a Unix
or Linux derivative and implement this type of fault tolerance.  It
requires a distributed lock manager be integrated with the kernel.
That lock manager requires the OS and file system both support the
concept of a ___record___.  Since the nodes will come and go, the OS
kernel needs to support logicals which are protected by varying
category or ACL levels.  Once you have a lock manager, you can begin
to integrate into the kernel a transaction manager, which will rely on
the lock manager, the logicals, the ACL's, and the kernel level
concept of a record.

When Unix chose streams, it sealed its fate.  Every organization which
attempts to put it in a situation which requires distributed fault
tolerant capabilities is going to have a catastrophic failure which
results in huge financial losses along with (most likely) the loss of
human life.

It would be easier to add a Bash shell to OpenVMS than to redevelop a
Unix kernel which had the concept of a record.