Question

原文Q： 我想知道是否有人有过将大型Cobol / PL1代码库迁移到Java的经验？

流程的自动化程度以及输出的可维护性如何？

从交易到OO的转变如何？

在此过程中学到的任何经验教训或可能有益的资源/白皮书都将受到赞赏。

编辑7/7：当然NACA方法很有意思，在发布JAVA版本之前继续对COBOL代码进行BAU更改的能力对任何组织都有好处。

与COBOL布局相同的过程Java的参数，使编码人员在熟悉Java语言时感到舒适，这对于拥有大量代码库的大型组织来说是一个有效的论据。正如@Didier所指出的那样，每年节省300万美元可以在任何BAU变化中提供大量填充的空间，以便持续重构代码。正如他所说，如果你关心你的人，你会找到一种让他们快乐的方法，同时逐渐挑战他们。

我从@duffymo到

的建议中看到了这个问题

最好尝试并真正理解根本问题并重新表达作为面向对象的系统

如果您正在进行任何BAU更改，那么在LONG项目生命周期内对您的新OO系统进行编码时，您最终会编码＆amp;测试双倍的变化。这是NACA方法的主要好处。我有一些将Client-Server应用程序迁移到Web实现的经验，这是我们遇到的主要问题之一，由于BAU更改而不断变换需求。它使PM＆amp;安排真正的挑战。

感谢@hhafez，他的经验非常好，因为“相似但略有不同”，并且从Ada到Java的自动代码迁移经验相当令人满意。

感谢@Didier的贡献，我还在研究你的方法，如果我有任何问题，我会给你留言。

Answer 1

更新6/25：一位朋友刚跑过NACA Cobol转Java转换器。看起来很有趣，它被用来翻译4米线的Cobol，准确度达到100％。这是NACA open source project page。我见过的其他转换器都是专有的，材料显然缺乏成功案例和详细的示例代码。 NACA值得一看。

更新7/4： @Ira Baxter报告说Java输出看起来很Cobol-esque，绝对可以。对我来说，这是自动翻译的自然结果。我怀疑我们会找到一个更好的翻译。这也许是对逐步重写方法的争论。

更新2/7/11： @spgennard指出JVM上有一些Cobol编译器，例如Veryant的isCobol Evolve。这些可用于帮助逐步转换代码库，但我认为OP对自动源转换更感兴趣。

我对此非常谨慎。（我曾经为一家自动纠正 Cobol和PL / I程序的Y2K公司工作，并做了将Cobol的许多方言转换成我们的中间分析形式的前端编译器，还有一个代码生成器。）我的感觉是，你最终会得到一个Java代码库，它仍然不够优雅且不能令人满意。您可能会遇到性能问题，依赖于供应商提供的库，生成的错误代码等等。你肯定会招致巨大的测试费用。

从头开始使用新的面向对象设计可能是正确的方法，但您还必须仔细考虑代码库所代表的数十年存储知识。通常，您的新代码可能会遗漏许多细微之处。另一方面，如果您很难找到维护原有系统的人员，您可能无法做出选择。

一种渐进的方法是首先升级到Cobol 97.这会增加面向对象，因此您可以在添加新功能时单独重写和重构子系统。或者您可以用新编写的Java替换单个子系统。

有时您可以使用现成的软件替换组件：我们帮助一家大型保险公司在20世纪50年代创建的传统语言中仍然拥有200万行代码。我们将其中的一半转换为符合Y2K标准的遗留语言，并且他们用外部供应商购买的现代工资单系统取代了另一半。

Answer 2

显然我们打算获得与原始cobol非常接近的初始java代码，以便于人们的迁移：他们找到了他们在cobol中以完全相同的结构编写的旧应用程序。

我们最重要的目标之一是让初始开发人员参与进来：这就是我们实现这一目标的方式。当应用程序迁移到Java时，这些人可以在进一步开发/重构它时开始更多OO。

如果您不关心迁移人员，可以使用其他策略。

此1对1转换也使100％自动转换更简单＆amp;更快：好的结果是我们更快地节省了我们的经常性储蓄（300万欧元/年）：我们估计12-18个月。那些早期的储蓄显然可以再投资于OO重构

随时与我联系：didier.durand@publicitas.com或mediaandtech@gmail.com

迪迪埃

Answer 3

我的经历类似但略有不同。我们在Ada（0.5Mloc超过15年）中有一个大而旧的代码库，最近转换为Java。它被外包给提供自动/手动转换组合的公司。他们还进行了测试，以验证Ada和Java系统的行为是否相同。

它的某些部分是用Ada 95编写的（即有OOP的可能性），但其中大部分都不是

现在是的，代码首先不符合用Java编写的相同代码标准，但是从那时起我们就已经成功使用它（18个月了），没有重大问题。我们获得的主要优势是现在我们可以找到更多开发人员来维护我们的代码库，并具备生成可维护代码的技能。（任何人都可以在Ada中开发，但是如果你没有任何其他语言，那么你可能会得到不可维护的代码）

Answer 4

从风险规避的角度来看，NACA方法绝对有道理。重用他们的工具可能不会。他们使用工具的开发来让他们的人员在java和linux中加快速度。

NACA转换的结果不够好，甚至不是OO，并且难以招聘新人。但它是可测试的，可以重构，你可以插入更好的翻译。

[编辑] 艾拉，你似乎没有风险意识。

将cobol程序员发送到java课程并不会让他们编写可用的面向对象的代码。这需要几年时间。在此期间，他们的工作效率将非常低，您基本上可以丢弃他们在第一年编写的所有代码。此外，您将失去10-20％的程序员，他们不愿意或无法进行过渡。很多人不喜欢回到初学者状态，它会影响啄食顺序，因为一些程序员比其他程序员更快地学习新语言。

NACA方法允许业务继续工作，并且不会给组织带来不必要的压力。转换的时间表是独立的。在OO专家写的java中有一个单独的翻译允许老团队逐渐接触java。编写测试用例可以增加新java团队中的领域知识。

真正的oo系统是翻译者，这是插入更好的翻译者的地方。这样做很容易，您不必触摸生成的代码。如果生成的代码足够丑陋，那就会自动发生：:)）

旧程序员将改变cobol输入;
新的java会改变翻译。

[翻译一次] 是一个糟糕的策略。不要那样做。如果您需要编辑生成的代码，请维护一个映射回来。这可以自动化。应该是。在Smalltalk图像中执行这些操作要容易得多，但您可以使用文件执行此操作。有些人在相同的工件上保持不同的观点有很多经验：芯片设计师会想到。

应该对翻译人员进行检测，这样您就可以创建例如

的日常计数

cobol输入组件;
OO java输入组件;
cobol样式输出组件;
OO样式输出组件。

您可能需要阅读： Peter van den Hamer＆amp; Kees Lepoeter（1996）管理设计数据：CAD框架，配置管理和数据管理的五个维度，IEEE会议论文集，Vol。 1996年1月第84号第1号

[移动Cobol平台] 从大型机上的Cobol转移到Windows / Linux上的Cobol可能是NACA团队可行的策略，但问题是如何转向Java。如果长期目标是建立一个现代的OO系统，并以尽可能少的操作风险到达那里，NACA的方法是合理的。不过，这只是第一步。很多重构都将随之而来。

Answer 5

我很惊讶没人提到语义设计的DMS软件再造工具包。我过去研究过COBOL转换。那时我正在研究“自动编程”。在写一个翻译之前，我查阅了该领域的一系列先前的努力和产品。 Semantic Designs基于GLR的工具是最好的工具。

那是很多年前的事了。当时，该工具将COBOL翻译成现代语言，重构它，漂亮地印刷它等等。现在是它的链接。

http://www.semdesigns.com/Products/DMS/DMSToolkit.html

他们还在身边。他们扩展了这个工具。它更通用。它可以帮助人们进行自动转换或自定义转换工具。与Stephan指出的相似，它的设计是可扩展和可调整的。感谢Cyrus也提到了SoftwareMining。如果我将来遇到COBOL迁移，我也会调查它们。

Answer 6

我刚刚查看了NACA页面和文档。从他们的文件：

“生成的java使用类似Cobol的语法。它与原始Cobol语法尽可能接近，当然还有Java语言的限制。生成的代码看起来不像传统的本机java，并且从应用程序的角度来看不是面向对象的。这是一个设计强有力的选择，可以使Cobol开发人员顺利迁移到Java环境。目标是将业务知识掌握在编写原始Cobol程序的人手中。“

我没有看到一个例子，但引用给出了结果的强烈味道。它的COBOL用Java编码。

你可以随时通过一种语言建立一个“翻译者” 简单地在目标语言中编写解释器。那是恕我直言在你最终结束时翻译语言的绝对可怕的方法两个世界中最糟糕的：你没有得到新语言的价值，而且你仍然必须知道旧的才能保持结果活。（难怪这个东西被称为“转码器”;我永远不会之前听过这个词。）

这个特技的论点是转储大型机的成本。哪里有证据表明转换计划的成本不要淹没储蓄？我怀疑事实是操作人员通过倾倒大型机来降低成本，他们也不在乎维护任务变得更加昂贵。虽然这可能是理性的对于操作人员来说，它是整个组织的愚蠢选择。

天堂帮助那些成为这个工具的受害者。

编辑2010年5月：我找到了NACA输出的一个例子; 他们的之一测试用例。这绝对是华丽的JOBOL。他们是一件好事保留他们的COBOL程序员，不想雇用任何Java程序员。在您阅读本文时，请务必记住这是 Java 代码。

/*
 * NacaRTTests - Naca Tests for NacaRT support.
 *
 * Copyright (c) 2005, 2006, 2007, 2008 Publicitas SA.
 * Licensed under GPL (GPL-LICENSE.txt) license.
 */

import idea.onlinePrgEnv.OnlineProgram;
import nacaLib.varEx.*;

public class TestLong extends OnlineProgram
{
  DataSection WorkingStorage = declare.workingStorageSection();

  Var W3 = declare.level(1).occurs(10).var();
  Var V9Comp010 = declare.level(5).pic9(10).var();
  Var V9Comp014V4 = declare.level(5).pic9(14, 4).var();
  Var VX10 = declare.level(5).picX(10).var();

  public void procedureDivision()
  {
    setAssertActive(true);

    move("9876543210", VX10);
    assertIfDifferent("9876543210", VX10);

    move(VX10, V9Comp010);
    long l = V9Comp010.getLong();
    assertIfFalse(l == 9876543210L);

    multiply(1000, V9Comp010).to(V9Comp014V4);
    assertIfFalse(9876543210000L == V9Comp014V4.getLong());

    String cs = V9Comp010.toString();
    cs = V9Comp014V4.toString();
    assertIfDifferent("9876543210000.0000", V9Comp014V4);

    inc(V9Comp010);
    assertIfFalse(9876543211L == V9Comp010.getLong());

    CESM.returnTrans();
  }

孩子：这只能由专业人士完成。不要在家里尝试这个。

Answer 7

你说的是reengineering。好消息是全世界很多人都试图这样做。遗憾的是，遗留应用程序重新设计存在许多问题：从缺失的源代码开始，再到编译器构造和图形理论领域的复杂算法。

自动翻译的想法很受欢迎，直到你尝试转换某些东西。通常结果很糟糕且不可维护。它比原始复杂的应用程序更难以维护。从我的角度来看，每个允许从遗留语言到现代语言自动翻译的工具都非常注重营销：它确切地说明了人们想要听到的“将你的应用程序从...转换为Java，忘记了！”，而不是你购买合同，然后你明白你非常依赖于工具（因为没有它你就不能对你的应用程序做任何改变！）。

替代方法是“理解”：该工具，可让您非常详细地了解您的遗留应用程序。您可以将其用于维护，记录或重新创建新平台。

在Microfocus去年购买它并将开发转移到另一个国家之前，我对Modernization Workbench历史有所了解。有大量复杂的分析工具，以及支持的目标语言（包括Java）的数量。但是没有客户真正使用自动代码生成，因此生成部分的开发被冻结了。据我所知，PL / I支持主要是实现的，但它从未完成。但是你仍然可以尝试，也许这就是你要找的东西。

将旧版Cobol / PL1迁移到Java的经验

7 个答案: