Any conversion tool would have risks associated with it, and the resulting code would have to undergo a lot of testing.
Given that a lot of these systems are in use daily to run a business, a lot rides on the continuing operation. So it is not just "how long" or "how expensive", but can we trust it to work 100% the same.
One will always find tools to convert one language to another - they usually go by the term "compilers".
There is always a shortcoming with compilers that have to perform the task of converting code in language X to language Y, especially when the said code was written by a person. That shortcoming happens to be the fact that readbility is often lost in the process of translation. There is no guarantee that the code compiled from COBOL to Java will be understood by any programmer, so in effect the cost of translation has actually increased. In fact, it is difficult to define readability in such a context.
Lack of readability and understandability translates into lack of knowledge of runtime behavior of the translated code. Besides there is no guarantee that people understand the original code completely; surely they do understand bits and pieces of it.
Probably a little of both. There are companies that provide tools and services for conversion using both automated and manual techniques.
Many companies, however, follow the "ain't broke" philosophy, which is likely as wise as anything. Especially since many conversions result in attempts to "improve" the existing system or try to introduce modern software design/construction philosophies and result in a mess.
Many systems written in Cobol have many transactions going though them. They work well on the mainframe platforms that they run on. It would be risky to change them just for the sake of change.
I think some organizations could find it useful, particularly organizations where interfacing with/designing around legacy code has become more costly and problematic than converting the code to Java (or another language)
Cobol program files are super long and just about always on ultra-secure mainframes. Usually the Java developers don't have access to them.
Colleges & Universities haven't taugh Cobol for more than 20 years. As a result, all of the really top-notch Cobol developers have moved up in their companies to be replaced with a bunch of tech school grads. These people didn't love programming enough to be hackers (or they'd do C, Python, C++, whatever and wouldn't have taken a course) or enough to go school (and be Java, .Net, Python, whatever).
Java developers generally lose their minds when they look at Cobol programs in their 50,000 line glory, so they aren't any help.
There really aren't any documents, and the logic is so tight in these programs that you should really just read them and convert them.
Most of these companies are financial companies where the best way to blowup and not be in the industry anymore is to screw something up. Good way to screw something up is to tack something like converting a critical task from Cobol to Java.
It's going to take a long time - every so often, part of one of the programs stops working or can't do something, and it gets replaced. I don't see a lot of senior managers having the stomach for the all of the FUD in one of these projects, and the timeframes are pretty long in terms of return on money spent.
Something to realize about old COBOL applications, besides the language dissimilarity, is that at a lot of data structures built in these applications don't conform to any later RDBMS structure, so really you would be talking about rethinking a lot of the underlying architecture and design, not just changing the language syntax, and replacing that would have a lot of performance risk once it hit real world loads, even if it could be QA'd sufficiently.
The bottom line is that it is more economical to bolt on new features in a modern language than rewrite it. As long as that continues to be the case, COBOL will continue to live on.
Cobol has the advantage of being fast for moving data around, which is what that kind of applications tend to do a LOT. Also the machines are designed for I/O, not processing speeds. Hence, any translation to another language will most likely be slower than the Cobol counterpart on identical or similar hardware, leaving no reason to do so.
Let me ask a counter question: WHY convert it, if you have something in place that works?
(Similar to tearing down a bridge ever 10 years just for rebuilding it again right afterwards - it is usually always cheaper just to maintain what you have).
There are translators around which can be modified at little cost to make it run on a specific machine or operating system and some are available from England and can be run there or on site. Standard versions exist for the major models (anyone can contact me about them). Cobol to another language source code or script is relatively easy to do automatically and would produce a text file for import into a source file on the target machine with 95 percent or more code compatibility. Simple manual amendments are all that are necessary before running the compiler or JIT software to achieve a new program - do not forget to amend the job command language or macro for mainframe jobs when testing or going live. New cobol compilers exist for ICT/ICL mainframes and one or two others and these compile faster than the old software and sometimes the new compiled program can run several times faster.
发布评论
评论（11）
目前，大量 COBOL 代码（我估计超过 90%）是无法测试的。
没有人知道它真正的作用是什么。
他们知道——至少——它在大多数时候都能完成预期的工作。如果没有，错误就会被发现。
更糟糕的是，一定比例的 COBOL 只是 COBOL 其他部分中错误的解决方法。
因此，如果你仔细观察它，你会发现你不知道到底发生了什么。您无法创建测试用例。
事实上，您会发现大多数组织甚至无法就什么是“正确”达成一致。但他们愿意在现有的条件上做出妥协。
检查核心业务处理的成本和风险是不可想象的。
Currently, a large volume of the COBOL code (I'd estimate well over 90%) is untestable.
No one knows what it really does.
They know that -- minimally -- it does the expected job most of the time. And when it doesn't, the bugs are known.
Worse, some percentage of COBOL is just workarounds for bugs in other parts of the COBOL.
Therefore, if you subject it to any scrutiny, you'll find that you don't know what's really going on. You can't create test cases.
Indeed, you'll find that most organizations can't even agree on what's "right". But they're willing to compromise on what's available.
The cost and risk of examining the core business processing is unthinkable.
任何转换工具都会有与之相关的风险，并且生成的代码必须经过大量测试。
鉴于许多此类系统每天都在使用来运营业务，因此很大程度上取决于持续运营。因此，问题不只是“多长时间”或“多贵”，而是我们能否相信它能 100% 一样工作。
Any conversion tool would have risks associated with it, and the resulting code would have to undergo a lot of testing.
Given that a lot of these systems are in use daily to run a business, a lot rides on the continuing operation. So it is not just "how long" or "how expensive", but can we trust it to work 100% the same.
人们总是会找到将一种语言转换为另一种语言的工具——它们通常被称为“编译器”。
编译器总是有一个缺点，必须执行将 X 语言的代码转换为 Y 语言的任务，特别是当所述代码是由人编写时。这个缺点恰好是在翻译过程中常常失去可读性。无法保证从 COBOL 编译为 Java 的代码会被任何程序员理解，因此实际上翻译成本实际上增加了。事实上，在这样的背景下很难定义可读性。
缺乏可读性和可理解性意味着缺乏对翻译代码的运行时行为的了解。此外，不能保证人们完全理解原始代码；当然，他们确实了解其中的点点滴滴。
One will always find tools to convert one language to another - they usually go by the term "compilers".
There is always a shortcoming with compilers that have to perform the task of converting code in language X to language Y, especially when the said code was written by a person. That shortcoming happens to be the fact that readbility is often lost in the process of translation. There is no guarantee that the code compiled from COBOL to Java will be understood by any programmer, so in effect the cost of translation has actually increased. In fact, it is difficult to define readability in such a context.
Lack of readability and understandability translates into lack of knowledge of runtime behavior of the translated code. Besides there is no guarantee that people understand the original code completely; surely they do understand bits and pieces of it.
可能两者都有一点。有些公司使用自动和手动技术提供转换工具和服务。
然而，许多公司都遵循“不会破产”的理念，这可能是明智之举。特别是因为许多转换导致尝试“改进”现有系统或尝试引入现代软件设计/构建哲学并导致混乱。
Probably a little of both. There are companies that provide tools and services for conversion using both automated and manual techniques.
Many companies, however, follow the "ain't broke" philosophy, which is likely as wise as anything. Especially since many conversions result in attempts to "improve" the existing system or try to introduce modern software design/construction philosophies and result in a mess.
许多用 Cobol 编写的系统都有许多交易通过它们。它们在运行的大型机平台上运行良好。仅仅为了改变而改变它们是有风险的。
Many systems written in Cobol have many transactions going though them. They work well on the mainframe platforms that they run on. It would be risky to change them just for the sake of change.
我认为一些组织可能会发现它很有用，特别是那些与遗留代码进行交互/设计的组织比将代码转换为 Java（或其他语言）的成本更高且问题更多。
I think some organizations could find it useful, particularly organizations where interfacing with/designing around legacy code has become more costly and problematic than converting the code to Java (or another language)
这里有几个因素：
这将需要很长时间 - 时不时地，其中一个程序的一部分会停止工作或无法执行某些操作，然后它就会被替换。我没有看到很多高级管理人员能够忍受这些项目中的所有 FUD，而且就投资回报而言，时间框架相当长。
There are a few factors here:
It's going to take a long time - every so often, part of one of the programs stops working or can't do something, and it gets replaced. I don't see a lot of senior managers having the stomach for the all of the FUD in one of these projects, and the timeframes are pretty long in terms of return on money spent.
COBOL 实际上是一种出色的 DSL（领域特定语言）。
它的领域是嵌入（主要）后端应用程序中的业务规则。
找到另一种语言......
......并且您将拥有后端业务应用程序的杀手级应用程序。
COBOL is, in effect, a superb DSL (domain specific language).
It's domain is business rules as embedded in (mainly) backend applications.
Find another language that....
....and you will have the killer application for backend business applications.
关于旧的 COBOL 应用程序，除了语言差异之外，需要认识到的是，这些应用程序中构建的许多数据结构不符合任何后来的 RDBMS 结构，因此实际上您会谈论重新思考许多底层架构和设计，而不仅仅是改变语言语法，一旦达到现实世界的负载，替换它就会带来很大的性能风险，即使它可以得到充分的质量保证。
最重要的是，用现代语言添加新功能比重写它更经济。只要这种情况继续存在，COBOL 就会继续存在。
Something to realize about old COBOL applications, besides the language dissimilarity, is that at a lot of data structures built in these applications don't conform to any later RDBMS structure, so really you would be talking about rethinking a lot of the underlying architecture and design, not just changing the language syntax, and replacing that would have a lot of performance risk once it hit real world loads, even if it could be QA'd sufficiently.
The bottom line is that it is more economical to bolt on new features in a modern language than rewrite it. As long as that continues to be the case, COBOL will continue to live on.
Cobol 的优点是移动数据快速，这是此类应用程序经常做的事情。此外，这些机器是针对 I/O 而设计的，而不是针对处理速度。因此，任何对另一种语言的翻译很可能会比相同或相似硬件上的 Cobol 翻译慢，因此没有理由这样做。
让我问一个反问题：如果你有可行的东西，为什么要转换它？
（类似于每隔 10 年拆除一座桥梁，然后立即重建它 - 通常维护现有的东西总是更便宜）。
Cobol has the advantage of being fast for moving data around, which is what that kind of applications tend to do a LOT. Also the machines are designed for I/O, not processing speeds. Hence, any translation to another language will most likely be slower than the Cobol counterpart on identical or similar hardware, leaving no reason to do so.
Let me ask a counter question: WHY convert it, if you have something in place that works?
(Similar to tearing down a bridge ever 10 years just for rebuilding it again right afterwards - it is usually always cheaper just to maintain what you have).
有一些翻译器可以以很少的成本进行修改，使其在特定的机器或操作系统上运行，有些可以从英国获得，可以在那里或现场运行。主要型号都有标准版本（任何人都可以联系我了解它们）。将 Cobol 转换为另一种语言源代码或脚本相对容易自动完成，并且会生成一个文本文件以导入到目标计算机上的源文件中，并且具有 95% 或更高的代码兼容性。在运行编译器或 JIT 软件以实现新程序之前，只需进行简单的手动修改即可 - 在测试或上线时不要忘记修改大型机作业的作业命令语言或宏。新的 cobol 编译器适用于 ICT/ICL 大型机和其他一两个软件，它们的编译速度比旧软件更快，有时新编译的程序运行速度可以快几倍。
There are translators around which can be modified at little cost to make it run on a specific machine or operating system and some are available from England and can be run there or on site. Standard versions exist for the major models (anyone can contact me about them). Cobol to another language source code or script is relatively easy to do automatically and would produce a text file for import into a source file on the target machine with 95 percent or more code compatibility. Simple manual amendments are all that are necessary before running the compiler or JIT software to achieve a new program - do not forget to amend the job command language or macro for mainframe jobs when testing or going live. New cobol compilers exist for ICT/ICL mainframes and one or two others and these compile faster than the old software and sometimes the new compiled program can run several times faster.