I would port them to ... um ... COBOL. Yes, that's it. COBOL.
Sorry, couldn't resist.
Seriously, there are COBOL compilers for current platforms out there and, unless we know a little more about why the code has to be ported, we may not be able to help.
Is the platform on which it runs obsolete? Is management just pushing for a more 'modern' solution? Are you having to move stuff from System z to Windows (ugh!)?
COBOL (in its purest form, not that OO-COBOL rubbish) is mostly a simple procedural language (ReportWriter notwithstanding) so will translate to any of the other procedural languges fairly well:
C.
C++ without classes
Java, although you can't avoid classes unless you have one big honkin' singleton.
Pascal (swapping one 'dead' language for another).
所以我不会将 COBOL 程序简单地移植到另一种语言； 我会将其移植到合适的 ETL 技术，例如 SQL Server Integration Services (SSIS) 或至少其前身 DTS（SQL 数据转换服务）。 SSIS 意味着使用VB.NET（至少在SQL Server 2005 中），但这应该不是问题。
Well, you should consider what inputs COBOL programs usually get.
COBOL was designed to process large amounts of fixed-width formatted text as input, to output in much the same manner. This sounds more like an ETL process to me than anything else.
So i wouldn't port COBOL programs to simply another language; I'd port it to suitable ETL technologies such as SQL Server Integration Services (SSIS) or at least its predeccesor DTS - SQL Data Transformation Services. SSIS implies using VB.NET (at least in SQL Server 2005), but that shouldn't be a problem.
First one has to as why COBOL has to be ported? COBOL is a powerful time honored language which most likely still has more lines of code running payroll, accounting, etc. in production than any other language.
The least painful port would be Synergy DBL. This is a highly portable VM style update of DIBOL (Digital Business Oriented Language).
DIBOL used all of the good pieces from BASIC, FORTRAN and COBOL leaving out most of the bad.
If you following the above link you will see they have GUI, .NET and other enhancement tools. Just be certain there is a VM for whatever target OS you will be running on.
IBM Mainframe COBOL making heavy use of CICS, TCAM, IDMS, etc. will be a really tough port to anything else.
OpenVMS COBOL making use of DECForms or possibly even FMS will be a tough port without a screen handling package. Very old COBOL from those shops will make copious use of system services and run time library routines provided by the OS which won't be available on most other platforms. You will also have to read up on logicals and figure out how to implement something kinda-sorta-close-enough on your target.
What you will find with most mainframe and mid-range COBOL is that you are not porting just COBOL. There will be tons of system services which older COBOL made use of.
更好地支持结构化记录 - 可以像在 C 中一样使用 struct/union 组合，但我认为有时它会使标识符变得很长（至少对于我见过的程序）。
Goto 语句 - 没有它，重写程序时就必须完全分析程序的逻辑。
Goto 语句 - 没有它
可能还有其他不容易映射的特征。
I don't know much COBOL, but I don't think there is a current language which is a straight superset of it (so, it's not easy to directly map COBOL to the language). I see several problems:
Built-in support for decimal arithmetic - this rules out any modern language without operator overloading.
Better support for structured records - one could use struct/union combo as in C, but I think it would make identifiers very long sometimes (at least for programs I have seen).
Goto statements - without it, one would have to completely analyze the logic of the program when rewriting it.
There may be other features which are not easy to map.
If you mean rewrite, then yes, choose a language. I would suggest a web interface, java or .Net, to rewrite in.
If the code needs to run exactly like it runs now, any "porting" conversion will only do harm.
If you must change platforms for some reason, you can use COBOL on another platform.
What has worked best in my experience is to try separating components or services from each other, and either converting small pieces individually or just writing new code in a preferred language, keeping the COBOL running in the back-end.
I'd personally perform this decision based upon the program's intended design, rather than its current implementation. If you want a straight-out line-for-line port, though, I'd probably say c/c++.
Perhaps instead of immediately looking at a new language you could consider transitioning some of your code to a contemporary framework like .Net - you might find that a good intermediatery solution, until you're ready to go the whole hog.
There are a few Cobol compilers for .NET available such as Fujitsu's NetCOBOL.
I once was involved porting some COBOL stuff to C (1989 or so.) The COBOL in question was code to monitor burglar alarms, fire alarms, etc. It was the kind of program that is suited to a more real-time kind of environment. Poll these gazillion customer field devices so many times per minute, etc. Looking "for features in a language that map well to COBOL's design" ignores the fact that there are a lot of COBOL programs out there that ignore COBOL's design.
因此，方法是保留 COBOL 核心，但通过 Web 服务进行接口，并使用任何 CLR 兼容语言（C#、VB 等）进行新开发。
I would keep the COBOL core but expand around the edges.
Microfocus provide a tool called Enterprise Server which allows COBOL to interact with web services.
If you have a COBOL program A and another COBOL program B and A calls B via the interface section, the tool allows you to expose B's interface section as a web service.
For program A, you then generate a client proxy and A can now call B via a web service.
Of course, because B now has a web service any other type of program (command line, Windows application, Java, ASP etc.) can now also call it.
Also, they have a product called COBOL.NET which runs inside Visual Studio and translates COBOL to MSIL. This means that you can then link in any .NET components.
So the approach is to keep the COBOL core but interface via web services and do new developments in any CLR compliant language (C#, VB etc.)
发布评论
评论（9）
我会将它们移植到……嗯……COBOL。 对，就是那样。 科博尔。
抱歉，没能抗拒。
说真的，目前的平台上有 COBOL 编译器，除非我们更多地了解为什么必须移植代码，否则我们可能无法提供帮助。
它运行的平台是否已过时？ 管理层是否只是在推动更“现代”的解决方案？ 您是否必须将内容从 System z 迁移到 Windows（呃！）？
COBOL（以其最纯粹的形式，而不是 OO-COBOL 垃圾）主要是一种简单的过程语言（尽管有 ReportWriter），因此可以很好地转换为任何其他过程语言：
I would port them to ... um ... COBOL. Yes, that's it. COBOL.
Sorry, couldn't resist.
Seriously, there are COBOL compilers for current platforms out there and, unless we know a little more about why the code has to be ported, we may not be able to help.
Is the platform on which it runs obsolete? Is management just pushing for a more 'modern' solution? Are you having to move stuff from System z to Windows (ugh!)?
COBOL (in its purest form, not that OO-COBOL rubbish) is mostly a simple procedural language (ReportWriter notwithstanding) so will translate to any of the other procedural languges fairly well:
那么，您应该考虑 COBOL 程序通常会获得哪些输入。
COBOL 旨在处理大量固定宽度格式的文本作为输入，并以大致相同的方式输出。 对我来说，这听起来更像是一个 ETL 过程，而不是其他过程。
所以我不会将 COBOL 程序简单地移植到另一种语言； 我会将其移植到合适的 ETL 技术，例如 SQL Server Integration Services (SSIS) 或至少其前身 DTS（SQL 数据转换服务）。 SSIS 意味着使用VB.NET（至少在SQL Server 2005 中），但这应该不是问题。
Well, you should consider what inputs COBOL programs usually get.
COBOL was designed to process large amounts of fixed-width formatted text as input, to output in much the same manner. This sounds more like an ETL process to me than anything else.
So i wouldn't port COBOL programs to simply another language; I'd port it to suitable ETL technologies such as SQL Server Integration Services (SSIS) or at least its predeccesor DTS - SQL Data Transformation Services. SSIS implies using VB.NET (at least in SQL Server 2005), but that shouldn't be a problem.
第一个必须是为什么 COBOL 必须被移植？ COBOL 是一种功能强大、历史悠久的语言，与任何其他语言相比，它在生产中运行工资、会计等的代码行数很可能更多。
最不痛苦的端口是 Synergy DBL。 这是 DIBOL（面向数字业务的语言）的高度可移植的 VM 风格更新。
http://www.synergex.com/synergy-dbl/
DIBOL 使用了所有来自 BASIC、FORTRAN 和 COBOL 的优秀作品排除了大部分不好的东西。
如果您点击上面的链接，您将看到他们有 GUI、.NET 和其他增强工具。 只要确保有一个适用于您将运行的目标操作系统的虚拟机即可。
大量使用 CICS、TCAM、IDMS 等的 IBM 大型机 COBOL 将很难移植到其他任何东西。
如果没有屏幕处理包，使用 DECForms 甚至 FMS 的 OpenVMS COBOL 将是一个艰难的移植。 这些商店中非常古老的 COBOL 将大量使用操作系统提供的系统服务和运行时库例程，而这在大多数其他平台上是不可用的。 您还必须阅读逻辑知识并弄清楚如何在您的目标上实现一些足够接近的东西。
您会发现，对于大多数大型机和中型 COBOL，您不仅仅移植 COBOL。 旧版 COBOL 将使用大量系统服务。
First one has to as why COBOL has to be ported? COBOL is a powerful time honored language which most likely still has more lines of code running payroll, accounting, etc. in production than any other language.
The least painful port would be Synergy DBL. This is a highly portable VM style update of DIBOL (Digital Business Oriented Language).
http://www.synergex.com/synergy-dbl/
DIBOL used all of the good pieces from BASIC, FORTRAN and COBOL leaving out most of the bad.
If you following the above link you will see they have GUI, .NET and other enhancement tools. Just be certain there is a VM for whatever target OS you will be running on.
IBM Mainframe COBOL making heavy use of CICS, TCAM, IDMS, etc. will be a really tough port to anything else.
OpenVMS COBOL making use of DECForms or possibly even FMS will be a tough port without a screen handling package. Very old COBOL from those shops will make copious use of system services and run time library routines provided by the OS which won't be available on most other platforms. You will also have to read up on logicals and figure out how to implement something kinda-sorta-close-enough on your target.
What you will find with most mainframe and mid-range COBOL is that you are not porting just COBOL. There will be tons of system services which older COBOL made use of.
我不太了解 COBOL，但我认为当前没有一种语言是它的直接超集（因此，将 COBOL 直接映射到该语言并不容易）。 我看到几个问题：
对十进制算术的内置支持 - 这排除了任何没有运算符重载的现代语言。
对
更好地支持结构化记录 - 可以像在 C 中一样使用 struct/union 组合，但我认为有时它会使标识符变得很长（至少对于我见过的程序）。
Goto 语句 - 没有它，重写程序时就必须完全分析程序的逻辑。
Goto 语句 - 没有它
可能还有其他不容易映射的特征。
I don't know much COBOL, but I don't think there is a current language which is a straight superset of it (so, it's not easy to directly map COBOL to the language). I see several problems:
Built-in support for decimal arithmetic - this rules out any modern language without operator overloading.
Better support for structured records - one could use struct/union combo as in C, but I think it would make identifiers very long sometimes (at least for programs I have seen).
Goto statements - without it, one would have to completely analyze the logic of the program when rewriting it.
There may be other features which are not easy to map.
我个人会根据程序的预期设计而不是其当前的实现来执行此决定。 不过，如果您想要一个直接的逐行端口，我可能会说 c/c++。
I'd personally perform this decision based upon the program's intended design, rather than its current implementation. If you want a straight-out line-for-line port, though, I'd probably say c/c++.
也许您可以考虑将一些代码转换为现代框架（例如 .Net），而不是立即寻找新语言 - 您可能会发现这是一个很好的中间解决方案，直到您准备好全力以赴。
有一些适用于 .NET 的 Cobol 编译器，例如 Fujitsu 的 NetCOBOL。
Perhaps instead of immediately looking at a new language you could consider transitioning some of your code to a contemporary framework like .Net - you might find that a good intermediatery solution, until you're ready to go the whole hog.
There are a few Cobol compilers for .NET available such as Fujitsu's NetCOBOL.
我曾经参与将一些 COBOL 内容移植到 C 语言（1989 年左右）。所讨论的 COBOL 是用于监控防盗警报器、火灾警报器等的代码。它是一种适合更实时环境的程序。 每分钟对这些无数的客户现场设备进行多次轮询，等等。寻找“与 COBOL 设计很好地映射的语言中的功能”忽略了这样一个事实，即有很多 COBOL 程序忽略了 COBOL 的设计。
I once was involved porting some COBOL stuff to C (1989 or so.) The COBOL in question was code to monitor burglar alarms, fire alarms, etc. It was the kind of program that is suited to a more real-time kind of environment. Poll these gazillion customer field devices so many times per minute, etc. Looking "for features in a language that map well to COBOL's design" ignores the fact that there are a lot of COBOL programs out there that ignore COBOL's design.
我会保留 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 等）进行新开发。
I would keep the COBOL core but expand around the edges.
Microfocus provide a tool called Enterprise Server which allows COBOL to interact with web services.
If you have a COBOL program A and another COBOL program B and A calls B via the interface section, the tool allows you to expose B's interface section as a web service.
For program A, you then generate a client proxy and A can now call B via a web service.
Of course, because B now has a web service any other type of program (command line, Windows application, Java, ASP etc.) can now also call it.
Also, they have a product called COBOL.NET which runs inside Visual Studio and translates COBOL to MSIL. This means that you can then link in any .NET components.
So the approach is to keep the COBOL core but interface via web services and do new developments in any CLR compliant language (C#, VB etc.)