在选择一种语言来移植 COBOL 程序时，您会选择哪种语言，为什么？我不是在寻找答案“因为我熟悉 X 语言”。
我正在寻找一种能够很好地映射到 COBOL 设计的语言的功能。
更新：这些程序将运行到实用程序、数据处理、屏幕等。
问问题
1661 次
9 回答
8
我会将它们移植到……嗯……COBOL。对，就是那样。COBOL。
对不起，无法抗拒。
说真的，目前有适用于当前平台的 COBOL 编译器，除非我们更多地了解为什么必须移植代码，否则我们可能无法提供帮助。
它运行的平台是否已过时？管理层是否只是在推动更“现代”的解决方案？您是否必须将东西从 System z 转移到 Windows（啊！）？
COBOL（以其最纯粹的形式，而不是 OO-COBOL 垃圾）主要是一种简单的过程语言（尽管有 ReportWriter），因此可以很好地翻译成任何其他过程语言：
- C。
- 没有类的 C++
- Java，虽然你不能避免类，除非你有一个大的单身汉。
- Pascal（将一种“死”语言换成另一种）。
- 甚至 Python、Perl 等也可以工作。
于 2009-04-21T05:26:50.687 回答
4
好吧，您应该考虑 COBOL 程序通常会得到什么输入。
COBOL 旨在处理大量固定宽度的格式化文本作为输入，以几乎相同的方式输出。对我来说，这听起来更像是一个 ETL 过程。
所以我不会将 COBOL 程序简单地移植到另一种语言；我会将它移植到合适的 ETL 技术，例如 SQL Server 集成服务 (SSIS) 或至少它的前身 DTS - SQL 数据转换服务。SSIS 暗示使用 VB.NET（至少在 SQL Server 2005 中），但这应该不是问题。
于 2009-04-21T05:23:12.663 回答
3
第一个必须是为什么必须移植COBOL？COBOL 是一种功能强大的历史悠久的语言，与任何其他语言相比，它很可能在生产中仍然有更多的代码行来运行工资单、会计等。
最不痛苦的端口是 Synergy DBL。这是 DIBOL（面向数字业务的语言）的高度可移植的 VM 样式更新。
http://www.synergex.com/synergy-dbl/
DIBOL 使用了 BASIC、FORTRAN 和 COBOL 中所有好的部分，而忽略了大部分不好的部分。
如果您按照上面的链接，您会看到他们有 GUI、.NET 和其他增强工具。只要确定您将在其上运行的任何目标操作系统都有一个 VM。
大量使用 CICS、TCAM、IDMS 等的 IBM 大型机 COBOL 将成为其他任何东西的一个非常艰难的端口。
如果没有屏幕处理包，OpenVMS COBOL 使用 DECForms 甚至可能是 FMS 将是一个艰难的端口。来自这些商店的非常旧的 COBOL 将大量使用操作系统提供的系统服务和运行时库例程，这些例程在大多数其他平台上都不可用。您还必须阅读逻辑并弄清楚如何在您的目标上实现一些足够接近的东西。
对于大多数大型机和中型 COBOL，您会发现您不只是在移植 COBOL。将有大量旧 COBOL 使用的系统服务。
于 2018-05-12T20:51:57.417 回答
2
我对 COBOL 了解不多，但我不认为当前的语言是它的直接超集（因此，将 COBOL 直接映射到该语言并不容易）。我看到几个问题：
对十进制算术的内置支持——这排除了任何没有运算符重载的现代语言。
更好地支持结构化记录 - 可以使用 C 中的 struct/union 组合，但我认为它有时会使标识符变得很长（至少对于我见过的程序）。
Goto 语句 - 没有它，在重写程序时必须完全分析程序的逻辑。
可能还有其他不容易映射的特征。
于 2009-04-21T06:20:15.847 回答
2
- 我不得不说你不应该移植 COBOL。
- 如果您的意思是rewrite，那么是的，选择一种语言。我建议重写一个 web 界面，java 或 .Net。
- 如果代码需要像现在一样运行，任何“移植”转换只会造成伤害。
- 如果由于某种原因必须更改平台，您可以在另一个平台上使用 COBOL。
- 根据我的经验，最有效的方法是尝试将组件或服务彼此分离，或者单独转换小块，或者只用首选语言编写新代码，让 COBOL 在后端运行。
于 2012-04-06T22:08:15.460 回答
1
我个人会根据程序的预期设计而不是当前的实现来执行此决定。但是，如果您想要一个直接的 line-for-line 端口，我可能会说 c/c++。
于 2009-04-21T05:26:12.063 回答
1
也许您可以考虑将一些代码转换到像 .Net 这样的现代框架，而不是立即研究一种新语言——您可能会发现这是一个很好的中间解决方案，直到您准备好全力以赴。
有一些适用于 .NET 的 Cobol 编译器，例如 Fujitsu 的NetCOBOL。
于 2009-04-21T05:28:12.603 回答
1
我曾经参与将一些 COBOL 的东西移植到 C（1989 年左右）。有问题的 COBOL 是用于监控防盗警报、火灾警报等的代码。这种程序适合更实时的环境. 每分钟轮询这些数以万计的客户现场设备如此之多，等等。寻找“以一种与 COBOL 设计良好映射的语言的特性”忽略了这样一个事实，即有很多 COBOL 程序忽略了 COBOL 的设计。
于 2009-04-21T05:37:52.470 回答
1
我会保留 COBOL 核心，但会在边缘扩展。
Microfocus提供了一个名为 Enterprise Server 的工具，它允许 COBOL 与 Web 服务进行交互。
如果您有一个 COBOL 程序 A 和另一个 COBOL 程序 B 并且 A 通过接口部分调用 B，则该工具允许您将 B 的接口部分公开为 Web 服务。
对于程序 A，然后生成客户端代理，A 现在可以通过 Web 服务调用 B。
当然，因为 B 现在有一个 Web 服务，任何其他类型的程序（命令行、Windows 应用程序、Java、ASP 等）现在也可以调用它。
此外，他们还有一个名为 COBOL.NET 的产品，它在 Visual Studio 中运行并将 COBOL 转换为 MSIL。这意味着您可以链接任何 .NET 组件。
因此，方法是保留 COBOL 核心，但通过 Web 服务进行接口，并使用任何符合 CLR 的语言（C#、VB 等）进行新的开发。
于 2009-04-21T19:38:14.213 回答