远离Itanium

Question

我们目前有一个用COBOL编写的大型业务关键应用程序，运行在OpenVMS (Integrity/Itanium)上。

几个月过去了，人们越来越多地猜测Itanium建筑的寿命。当然，在公开场合没有说什么，但是像这和这这样的文章描绘了一幅令人担忧的画面。虽然我找不到任何官方支持这一点，但甚至在我们公司的走廊里，惠普放弃了OpenVMS和HP，以及它。

我不敢相信我们在这方面是孤军奋战。

在我看来，有几种选择：

1. 模仿一些旧的硬件，并使用查隆-瓦克斯或夏龙-AXP这样的产品在上面运行应用程序。在我看来，优点是这个过程应该相对没有痛苦，特别是如果使用64位(AXP)选项的话。潜在的缺点是性能下降(虽然这应该被更快更快的硬件所抵消)；
2. 将基于HP的应用程序移植到更现代的COBOL方言，例如视觉COBOL。因此，优点是移植工作量相对较低(仍然是COBOL)，以及可以在Unix或Windows平台上运行应用程序的事实。缺点是，尽管您正在移植COBOL，但移植到不同的操作系统可能会使事情变得棘手(尤其是)。如果存在特定于OpenVMS的依赖项)；
3. 自动将COBOL转换成一种更现代的语言，如Java。这有一个明显的好处:立即从所有遗留问题中解放出来:硬件支持、操作系统支持，特别是找到管理员和程序员。除了这是一项很大的工作之外，一个明显的缺点是，一个人最终将得到非惯用的Java (或任何最终选择的目标语言)；可以说，随着时间的推移，这是可以改进的。
4. 从头开始重写(自然，使用现代技术)。任何做过这件事的人都知道这是多么的昂贵和费时。我把它包括进来只是为了使列表完整:)

请注意，不依赖于专有DBMS；数据库是基于ISAM文件的。

所以..。我的问题是：

当他们选择的平台是OpenVMS和COBOL?时，其他人面临着Itanium即将淘汰的问题，以保持业务的连续性。

更新：

我们已经从我们当地的惠普代表那里得到了一个官方保证，完整性/Itanium/OpenVMS将至少在2022年之前得到支持。我猜这意味着整个问题不是关于平台，而是关于语言(COBOL)。

Answer 1

这项工作的主要问题将是代码中特定于OpenVMS的部分。大多数在OpenVMS上开发的应用程序通常使用不易移植到另一个平台的例程和过程。相反，出于对特定语言兼容性的担忧，我首先关注应用程序使用的运行时例程和命令过程。

另一种方法可能是继续使用当前的应用程序，同时开发一个新的应用程序，或者修改一个商业上可用的应用程序以满足您的需要。虽然Itanium的长期状态存在疑问，但历史表明，OpenVMS在未来一段时间内仍将是可行的。目前仍有一些VAX机器用于业务关键应用程序。OpenVMS和它的硬件是稳定的，这是它长寿的主要原因。

丹

Answer 2

看来COBOL是让您担心的主要依赖项。我认为这张照片中的Itanium+OpenVMS只是一个平台。

你绝对不是唯一一个在OpenVMS上运行关键任务的人。惠普网站有OpenVMS路线图(包括Alpha和Integrity)，目前支持范围一直到2015年。甲骨文最近似乎试图利用它在不同领域的SUN资产。

无论如何，如果您的担忧很大(当然我们都担心COMPAQ，然后惠普，vax>>alpha>>Itanium在过去的过渡)，那么就有时间消除COBOL的依赖。

因此，我现在将研究从COBOL到更可移植语言的迁移路径(例如。C/C++ ANSII，没有平台扩展)。考虑到Oracle的活动，Java可能不是最好的选择。重写，多么令人不快，将更加进步，很可能会简化整个过程。人越早开始，就越早完成。

另外，除了仿真器，还有大量的二手硬件.具有讽刺意味的是，我刚刚认识的一家公司--在Integrity平台上取代misson--关键的Alphas -我猜，这是“公司测试需求”.

无所事事也是一种选择，尽管显然风险更大: OpenVMS平台被证明是可靠的，因此，找到一家可靠的第三方支持公司可能会延长您未来的硬件应变能力。

Answer 3

今年夏天的滚动路线图使移植OpenVMS看起来是一个很好的主意。

鉴于COBOL在世界上的存在，在可预见的将来，寻找支持COBOL的人将不是一个问题。如上所述，在其他平台上有COBOL编译器。问题在于应用程序使用的OpenVMS系统服务调用和DEC语言扩展。您没有提到数据存储的位置，因此最糟糕的情况是COBOL使用RMS。有一家公司在Linux和Unixes上提供许多OpenVMS系统服务的实现。在移植到另一个操作系统时不需要替换这些服务可能会降低复杂性。查看Sector7.com。