[Info-vax] VMS Forever?

[yyyc186]

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.