I have just returned from the OpenVMS Technical Seminar hosted by OpenVMS Engineering in Nashua, New Hampshire on November 19-21. The three days of sessions extensively covered topics including the assimilation of Itanium CPUs, hands-on training for Next Generation Alpha-based systems, E-Commerce, Probably, the hottest issue in the OpenVMS community is support for Intel's Itanium processor. The presentations on the Itanium effort were made by senior engineers from
the OpenVMS team, including Andrew Goldstein, Clair Grant, Stephen Hoffman, and Gaitan D'Antoni.
Mark Gorham, the VP in charge of OpenVMS also presented a keynote on policy and strategy for OpenVMS long term. He noted that while legal restrictions prevent the publication of plans beyond a rolling five year horizon, there is a
positive commitment to OpenVMS in the form the of the DII COE commitment
(columnist's note: DII COE requires a long term binding commitment to the platform of approximately 20 years, it is inconceivable to this columnist that HP would choose to limit sales and support of OpenVMS to the large, albeit finite defense sector, rather than amortize the expenses of the product line over the entire commercial space). Sales are reported to be healthy among existing and new customers. ISVs are joining the community, including recent
announcments from Legato and Veritas. In short, OpenVMS will actively be around long after we retire.
Perhaps the best quote of the symposium came from both the engineering
staff and management that the Itanium migration support will work at both
the source, and translation level; even for images that were already
VEST'ed from VAX to Alpha (translated on a binary, not source recompilation basis).
In short, we will be able to use VEST to translate an
image from VAX to Alpha, and re-translate the resulting image to Itanium. While this
tour-de-force was not unanticipated, it is welcome to be in the form of a
commitment.
The technical sessions covered many aspects of the Itanium support,
including some of the mechanics of the bootstrap process, the enhanced
calling standard on Itanium, and issues relating to roadmap and compiler
capabilities, including the use of industry-standard object and debugger
formats. All of the presentations showed an increasing level of
detail, even from similar presentations just over a month ago in St. Louis
at HPETS 2002. The presentations handily accounted for the major technical
issues, clearly showing that the "doom and gloom" FUD is just that, fear of
the unknown. For that matter, it was clear at the outset from the Itanium
architectural specifications published by Intel that OpenVMS could
feasibly assimilate Itanium. Compared to the introduction of Alpha (where
the architecture transitioned from 32-bit to 64-bit), the differences
between Alpha and Itanium are less disruptive to code bases (see the
author's presentation on
"The Third Porting",
which was presented at CETS 2001 and HPETS 2002). At the OpenVMS system
level, the processor change is an order of magnitude smaller (an "order of
magnitude" is a factor of 10) than the changes required during the
VAX to Alpha transition.
HP has also addressed the business issues which are of concern to many
installations, most every issue
I raised at the time of the Alpha/Itanium announcement in June 2001
has been addressed. Alpha systems will continue to be available and sold,
at least through 2006; systems will be supported after active sales ceases;
there are guarantees on purchases of Itanium systems, mixed architecture cluster
support, and other policies.
OpenVMS 8.2 will be the first release of "Production Quality" on the
Itanium platform, and will be released concurrently for all three patforms
(VAX, Alpha, and Itanium).
Unlike the VAX/Alpha effort, the Itanium effort is working from the
common source base with Alpha, so there will be few, if any functional
differences between OpenVMS on the Alpha and Itanium platforms (the
differences between Alpha and VAX will be preserved with Itanium), In
short, "VMS will be VMS", regardless of which platform it is executing on.
My next column will discuss some of the other interesting information
presented at the seminar (within the limits of the NDA, of course).
Biography:
Robert Gezelter is the Founding Principal of the consulting firm that bears his name (www.rlgsc.com).
The consulting practice emphasizes in-depth technical expertise in computer architectures, operating systems, networks, security, APIs, and related matters. Mr. Gezelter has worked with OpenVMS since the initial release of VAX/VMS in 1978.
His clients have ranged from small businesses to the Fortune 10 locally, nationally, and internationally.
He can be reached at gezelter@rlgsc.com.