Sure, there are folks keeping PDP-11 and undoubtedly yet older boxes
alive and operating, but is that a viable market for an operating
Is that a market that'll grow and attract newer customers?
VMS growth doesn't happen with VAX or Alpha gear, nor can growth happen
with Itanium gear post-Kittson. Nor does substantial VMS growth seem
particularly likely with current and likely future Itanium servers.
Some growth might start to happen when x86-64 support gets here and
significant new features start rolling out, but there's no schedule for
the x86-64 port and no certainty whether nor when VSI will complete
that porting work — VSI needs to get their V8.4-1H1 release and a
revenue stream going first.
Post by David Froble
I doubt VSI is going to have any time to even mention the words Alpha
or VAX for a while, but, while some might think they are dead products,
it seems as if there is still some old hardware in use, and, then,
there are those running the emulators.
In the case of VAX, there've been no new versions of OpenVMS VAX in ~13
the last of the new VAX servers were sold well over a decade ago, and
all software support for OpenVMS VAX ends in 2015 per the current HP
The last of the Alpha systems shipped out more than seven years ago,
and the Alpha "fleet average" is undoubtedly rather older than that,
and all OpenVMS Alpha support ends in 2018 per the HP roadmap.
Then there are the business questions: is this old gear even a viable
market? How much new software are these folks buying, how much support
are they buying, and what's keeping them on this old and very
inefficient gear and what might encourage them to upgrade or replace?
Post by David Froble
I'd think the more revenue streams that can be supported would be good for VSI.
For the long-term with VMS, I'd prefer / expect to see VSI support
their long-term support (LTS) releases for ~five years as is now
typical with other LTS environments, and provide a release map to
assist and to encourage folks to upgrade their VMS software or to
migrate their data and to replace their servers.
Whether VSI supports V9.x on Itanium or back-ports their (eventual,
planned) x86-64 work to Itanium, or extends support for the terminal
Itanium release isn't known, and probably hasn't even been particularly
considered yet. VSI needs to get OpenVMS I64 V8.4-1H1 out the door,
and to get their business — their web site, contract administration,
price lists and discounts, license tracking, support forums, internal
support databases, single-sign-on, networking and servers and the
physical plant, installing truck-loads of new Tukwila and Poulson and
other gear, customer calls and customer meetings and preparing and
delivering presentations, and all the rest of the baggage that a
software company needs to have — going.
VSI needs to build and test and then get customers over onto V8.4-1H1,
V8.4-1H2 and V9.x, too. Revenue.
As for support, doing what DEC and other older vendors have done in
years past — supporting some releases for ~15 years — strikes me as a
losing proposition these days. Particularly given software and
hardware replacement cycles, and the ever-lower software and support
prices. Beyond the obvious need for the support vendor to keep their
own 13+ year old systems around, all vendors involved are also
constrained on what features the support vendor and any of the
third-party software vendors can use on these older releases in the
available products and tools, and which makes development either
more difficult, or into a least-common-feature-driven process. And to
do that in an environment where the vendor's server prices and
software prices are dropping, and when newer-generation servers are
still getting more efficient? Something has to give, and for software
vendors — as one of the speakers from HP stated at the boot camp —
that's usually long-long-term support.
But why is someone running an emulator? ...
If it is to save money, he can save even more by running directly on X86.
That still involves a port, and porting code — even a
cross-architecture port of a VMS application — is more expensive than
just leaving the code as it is. Some organizations aren't spending
more than physical repairs, power and the minimal effort involved in
keeping critical applications and backups running within their existing
Performing application ports from one VMS architecture to another also
assumes that all prerequisite products or equivalent products are
available and affordable. This is not always the case. Binary
translation does not always resolve these cases, whether that's due to
technical limitations of the translation or due to reasons involving
product licensing or product support. Some of these ports can be quite
intractable, short of a very large infusion of cash.
 VMS is (presently) not very adept at mass deployments, and hardware
mass deployments require the sorts of infrastructure and network and
authentication services that VSI is (also) now undoubtedly building and
bootstrapping for itself.
 VAX or Alpha emulators can't be trusted to be exactly duplicate the
behavior of real hardware. When you're sorting out some bugs,
sometimes emulation — even if you've extended support to specific
emulators — requires access to the actual configurations with the
 VAX was and is a hassle to support, as it's missing hardware and
software features available on newer OpenVMS releases, meaning your
cross-platform tools and products either can't support OpenVMS VAX, or
can't use the newer features on the newer platforms, or will require
conditionalizing the code and documenting and maintaining different
support and different features. So there's added expense here, and
potentially on a platform where the customers might not be spending as
much money as the folks closer to the front of the product offerings.
 VSI doesn't have a bespoke hardware product offering (yet?), which
means VSI is entirely dependent on software and software support
revenues, and on any consulting and custom feature requests they choose
Pure Personal Opinion | HoffmanLabs LLC