体验将传统 Cobol/PL1 迁移到 Java
原始问题:我想知道是否有人有将大型 Cobol/PL1 代码库迁移到 Java 的经验?
ORIGINAL Q: I'm wondering if anyone has had experience of migrating a large Cobol/PL1 codebase to Java?
流程自动化程度如何，输出的可维护性如何?
How automated was the process and how maintainable was the output?
从事务性到 OO 的转变是如何进行的?
How did the move from transactional to OO work out?
我们将不胜感激在此过程中学到的任何经验教训或可能有益的资源/白皮书.
Any lessons learned along the way or resources/white papers that may be of benefit would be appreciated.
编辑 7/7: 当然，NACA 方法很有趣，在发布 JAVA 版本之前继续对 COBOL 代码进行 BAU 更改的能力对任何组织都有好处.
EDIT 7/7: Certainly the NACA approach is interesting, the ability to continue making your BAU changes to the COBOL code right up to the point of releasing the JAVA version has merit for any organization.
在与 COBOL 相同的布局中程序化 Java 的论点是让编码人员在熟悉 Java 语言的同时感到舒适，这对于拥有大量代码库的大型组织来说是一个有效的论点.正如@Didier 指出的那样，每年 300 万美元的节省为未来任何 BAU 更改提供了充足的空间，以持续重构代码.正如他所说，如果你关心你的员工，你就会找到一种让他们开心的方法，同时逐渐挑战他们.
The argument for procedural Java in the same layout as the COBOL to give the coders a sense of comfort while familiarizing with the Java language is a valid argument for a large organisation with a large code base. As @Didier points out the $3mil annual saving gives scope for generous padding on any BAU changes going forward to refactor the code on an ongoing basis. As he puts it if you care about your people you find a way to keep them happy while gradually challenging them.
我在@duffymo 的建议中看到的问题
The problem as I see it with the suggestion from @duffymo to
最好尝试并真正理解问题的根源并重新表达作为一个面向对象的系统
Best to try and really understand the problem at its roots and re-express it as an object-oriented system
如果您正在进行任何 BAU 更改，那么在对新的 OO 系统进行编码的 LONG 项目生命周期中，您最终会编码 &测试双倍的变化.这是 NACA 方法的主要好处.我有一些将客户端-服务器应用程序迁移到 Web 实现的经验，这是我们遇到的主要问题之一，由于 BAU 变化而不断改变需求.它使 PM &安排一个真正的挑战.
is that if you have any BAU changes ongoing then during the LONG project lifetime of coding your new OO system you end up coding & testing changes on the double. That is a major benefit of the NACA approach. I've had some experience of migrating Client-Server applications to a web implementation and this was one of the major issues we encountered, constantly shifting requirements due to BAU changes. It made PM & scheduling a real challenge.
感谢@hhafez，他的经验被很好地描述为相似但略有不同"，并且在从 Ada 到 Java 的自动代码迁移方面获得了相当令人满意的体验.
Thanks to @hhafez who's experience is nicely put as "similar but slightly different" and has had a reasonably satisfactory experience of an automatic code migration from Ada to Java.
感谢@Didier 的贡献，我还在研究你的方法，如果我有任何问题，我会给你留言.
Thanks @Didier for contributing, I'm still studying your approach and if I have any Q's I'll drop you a line.
推荐答案
6/25 更新: 一位朋友刚刚遇到了 NACA Cobol 到 Java 转换器.看起来很有趣，它被用来以 100% 的准确率翻译 4m 行 Cobol.这是 NACA 开源项目页面.我见过的其他转换器是专有的，并且这些材料明显缺乏成功案例和详细的示例代码.NACA 值得一看.
Update 6/25: A friend just ran across the NACA Cobol to Java converter. Looks quite interesting, it was used to translate 4m lines of Cobol with 100% accuracy. Here's the NACA open source project page. The other converters I've seen were proprietary, and the materials were conspicuously lacking success stories and detailed example code. NACA is worth a long look.
7/4 更新: @Ira Baxter 报告说 Java 输出看起来非常 Cobol-esque，这绝对是.对我来说，这是自动翻译的自然结果.我怀疑我们永远找不到更好的翻译.这或许支持逐步重写的方法.
Update 7/4: @Ira Baxter reports that the Java output looks very Cobol-esque, which it absolutely does. To me, this is the natural result of automatic translation. I doubt we'll ever find a much better translator. This perhaps argues for a gradual re-write approach.
2/7/11 更新:@spgennard 指出 JVM 上有一些 Cobol 编译器，例如 Veryant 的 isCobol Evolve.这些可用于帮助逐步转换代码库，尽管我认为 OP 对自动源转换更感兴趣.
Update 2/7/11: @spgennard points out that there are some Cobol compilers on the JVM, for example Veryant's isCobol Evolve. These could be used to help gradually transition the code base, though I think the OP was more interested in automated source conversion.
对此我会非常谨慎.(我曾经在一家公司工作，该公司为 Y2K 自动更正 Cobol 和 PL/I 程序，并做过前端编译器，将 Cobol 的许多方言转换为我们的中间分析形式，也是一个代码生成器.) 我的感觉是，您最终会得到一个 Java 代码库，但使用起来仍然不够优雅且令人不满意.您可能会遇到性能问题、对供应商提供的库的依赖、生成的代码有问题等等.您肯定会产生巨额测试费用.
I'd be very cautious about this. (I used to work for a company that automatically corrected Cobol and PL/I programs for Y2K, and did the front end compiler that converted many dialects of Cobol into our intermediate analytic form, and also a code generator.) My sense is that you'd wind up with a Java code base that still would be inelegant and unsatisfying to work with. You may wind up with performance problems, dependencies on vendor-supplied libraries, generated code that's buggy, and so on. You'll certainly incur a huge testing bill.
从头开始采用新的面向对象设计可能是正确的方法，但您还必须仔细考虑代码库所代表的数十年存储的知识.通常，您的新代码可能会遗漏许多细微之处.另一方面，如果您很难找到维护旧系统的人员，您可能别无选择.
Starting from scratch with a new object-oriented design can be the right approach, but you also have to carefully consider the decades of stored knowledge represented by the code base. Often there are many subtleties that your new code may miss. On the other hand, if you're having a hard time finding staff to maintain the legacy system, you may not have a choice.
一种渐进的方法是首先升级到 Cobol 97.这增加了面向对象，因此您可以在添加新功能时单独重写和重构子系统.或者，您可以用新编写的 Java 替换单个子系统.
One gradual approach would be to first upgrade to Cobol 97. This adds object-orientation, so you can rewrite and refactor subsystems individually when you add new functionality. Or you could replace individual subsystems with freshly-written Java.
有时您可以用现成的软件替换组件:我们帮助了一家非常大的保险公司，该公司在 1950 年代创建的旧语言中仍有 200 万行代码.我们将其中一半转换为符合 Y2K 的传统语言，然后他们用从外部供应商处购买的现代工资系统替换了另一半.
Sometimes you'll be able to replace components with off-the-shelf software: we helped one very large insurance company that still had 2m lines of code in a legacy language it created in the 1950s. We converted half of it to Y2K compliant legacy language, and they replaced the other half with a modern payroll system they bought from an outside vendor.
相关文章