经验迁移的遗产Cobol/PL1Java

StackOverflow https://stackoverflow.com/questions/1029974

题

原始问： 我想知道，如果任何人有经验的迁移的一个大型的Cobol/PL1codebase Java?

如何自动化的过程和如何维护的是本输出？

怎么移动从事务以OO的工作吗？

任何经验教训沿途或资源/白皮书，可能是有益处的，将不胜感激。

编辑7/7: 当然NACA的方法是有趣的，能够继续做你的BAU的变化以COBOL编码的权利的释放JAVA版本有值得为任何组织。

参数的程序在相同的布局的COBOL得到的编码一种舒适的感觉，同时熟悉Java语言是一种有效的参数对于一个庞大的组织与一个大型代码的基础。作为@Didier指出美元的3mil每年节省提供范围慷慨填补的任何BAU的变化展望未来"重构"的代码在持续的基础。正如他所说的那样，如果你关心你的人你找到一个办法让他们高兴的同时逐渐具有挑战性的。

这个问题，因为我看到它的建议，从@duffymo到

最好的尝试并真正地了解 问题的根源，并重新表达它 作为一个面向对象的系统

是的，如果你有任何BAU的改变正在进行，然后在漫长的项目周期的编码的新的OO系统的你结束了编码和测试的变化。这是一个主要益处NACA的方法。我已经有一些经验迁移的客户机-服务器应用于一个网络执行，这是一个重大的问题，我们遇到的不断变化的要求由于BAU的变化。它做到&调度的一个真正的挑战。

由于@hhafez人的经验是很好的把 "类似但略有不同的" 有一个相当令人满意的体验的自动代码移民从阿达到Java。

谢谢@Didier作出贡献，我仍然在研究你的方法，和如果我有任何问的我会放你一条线。

有帮助吗？

解决方案

更新6月25日：一位朋友刚跑过 NACA Cobol到Java转换器。看起来很有趣，它被用来翻译4米线的Cobol，准确度达到100％。这是 NACA开源项目页面。我见过的其他转换器都是专有的，材料显然缺乏成功案例和详细的示例代码。 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标准的遗留语言，并且他们用外部供应商购买的现代工资单系统取代了另一半。

其他提示

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

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

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

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

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

迪迪埃

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

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

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

从一个避免风险的观点，NACA的办法绝对有道理的。重复使用其工具可能不会。他们用的是开发的工具来获得他们的人的速度在爪哇和linux。

结果NACA转换是不足够，或甚至OO,并且使它难以雇用新人。但它是检验的，可以重组，并可以插在更好的翻译。

[编辑] 艾拉，你看起来不是很风险意识。

发送的cobol编程人员java然是不要让他们写可用面向对象的代码。那需要几年。在此期间，他们的生产效率会很低，基本上你可以扔掉所有的代码，他们编写的第一年。另外你会失去的10-20％你的程序员，谁都不愿意或能够作出的过渡。很多人不喜欢回到初级状态，这会影响的排序，因为一些程序挑选了新的语言很快于其他人。

NACA种方法允许企业继续工作，并把没有不必要的压力的组织。时间计划的转换是独立的。具有一个独立的翻译，书面通过面向对象的专家，允许逐渐暴露于java旧的团队。编写测试情况下会增加的领域知识的新的java队。

真正的oo系统是翻译，这是地方插在更好的翻译。使它容易做到，你没有接触所产生的代码。如果所产生的代码是丑陋的足够的，那就是将会发生什么自动：:)

  • 旧的程序员会改变的cobol输入；
  • new java那些将会改变的翻译。

[运行翻译，一旦] 是一个不好的策略。不这样做。如果你需要编辑产生的代码，维持 射回来。这可以是自动的。和应该的。这是一个很容易做这样的事情，在一般的图像，但是你可以做到这一文件。还有人有很多的经验维持不同的看法相同的项目：芯片设计师来考虑。

译者应检测，所以您可以创建的每日计算的，例如

  • cobol输入的部件；
  • OO java输入的部件；
  • cobol式输出组成部分；
  • OO式的产出组成。

你可能会想读：Peter van den哈默&基斯Lepoeter(1996)管理设计的数据：五尺寸的CAD框架、配置管理和数据管理、程序IEEE，第一卷。84，没有。1,January1996

[移动的Cobol平台] 从Cobol上的主机，以Cobol于Windows/Linux可能是一个可行的战略NACA队，但问题是关于移动java。如果长期目标是有一个现代化的OO系统，并得到有用尽可能少业务风险，如有可能，NACA方法是健全的。这只是第一步，虽然。很多重构要遵循。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

编辑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();
  }

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

许可以下： CC-BY-SA 和 归因
不隶属于 StackOverflow
scroll top