将遗留的Cobol / PL1迁移到Java的经验

原文问:我想知道是否有人有将大型Cobol / PL1代码库迁移到Java的经验?

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

从交易到OO的转变如何?

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


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

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

我从@duffymo的建议看到的问题

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

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

感谢@hhafez,他的经验很好地被认为是“相似但略有不同”,并且从Ada到Java的自动代码迁移有着相当令人满意的体验。

感谢@Didier的贡献,我还在研究你的方法,如果我有任何Q,我会告诉你一句话。

更新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对自动源转换更感兴趣。


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

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

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

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

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

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

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

这种一对一的转换也使100%自动化转换变得更简单,更快:好的结果是我们更快地节省了(3百万欧元/年):我们估计12-18个月。 那些早期的储蓄显然可以再投资于OO重构

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

迪迪埃

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

它的某些部分用Ada 95编写(即有OOP的可能性),但大部分都不是

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

从风险规避的角度来看,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&Kees Lepoeter(1996)管理设计数据:CAD框架,配置管理和数据管理的五个维度,IEEE会议论文集,Vol。 1996年1月第84号第1号

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

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

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

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

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

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

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

替代方法是“理解”:该工具,允许您非常详细地了解您的遗留应用程序。 您可以将其用于维护,记录或重新发布新平台。

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

我只看了NACA页面和文档。 从他们的文件:

“生成的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(); } 

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