Is there anything preventing interoperability between modern languages and COBOL?
我正在阅读有关人们在使用仍在使用 COBOL 的政府系统时如何难以找到使用它的人的文章。我还在阅读有关 Fortran(一种比 COBOL 早两年出现的语言)如何通过正确的库与 C、C、R 和 Python 互操作的信息。
这允许 Fortran 脚本在某种程度上与现代编程语言一起工作，甚至可以用现代编程语言创建可以与 Fortran 代码一起工作的脚本，从而使 Fortran 新手更容易使用它。是否有任何特殊问题阻止 COBOL 与其他编程语言(如 SQL(用于类似于 COBOL 的数据库)具有类似的互操作性，这将使通常可能不学习 COBOL 的现代程序员更容易使用它？
Q1：有什么会阻碍现代语言和 COBOL 之间的互操作性吗？
A1：与上述类似的简短回答：不，实际上经常这样做。
但这可能取决于为读者定义的"现代语言"。
即使使用"真正的"COBOL(不是一些"闪亮"[可能被解读为"混合"]"托管 COBOL")，在大多数情况下，您也可以自由地直接调用任何 C 函数，因此或多或少可以调用任何东西(至少使用C package器)，也可以像在操作系统上那样调用二进制文件(`CALL 'SYSTEM' USING 'some-executabe-or-script"param1""param2"' 是一个常见的扩展)。
要直接调用任何"本机代码"(如 Win32 或 POSIX)，您显然必须确保使用正确的参数定义，但 COBOL 2002 有类似
另外，通常有直接的方式与套接字服务器、HTTP(S)、XML、JSON、...进行互操作；并且许多 COBOL 实现还允许
Q2：是否有任何特殊问题阻止 COBOL 与 [...] SQL 实现 [...] 互操作性？
A2：没有，而且 SQL 是 COBOL 中很常见的直接使用：
很多人会说SQL不是"编程语言"。它是一种查询语言，可用于不同的环境，包括 COBOL。
根据所使用的环境，
Q3：[...东西] 会让那些通常不会学习 COBOL 的现代程序员更容易使用它吗？
...这是一个完全不同的问题，无论"现代程序员"是什么。
程序员要了解一门编程语言，完全取决于程序员和资源(如时间、手册、教程、导师)以及程序员的意愿。许多人实际上并不"想"学习 COBOL(出于我听说过但不理解或不同意的原因)，其他人错过了一些资源(GnuCOBOL 提供免费编译器，几乎所有 COBOL 编译器都有他们的手册可在线获取，并且 COBOL 的 ISO 工作组也在线发布标准草案；您通常可以在 COBOL 讨论论坛或邮件列表中找到导师，以及许多示例)。
COBOL 的一个特别之处通常不是语言本身，而是它使用的环境("大型机"使用作业控制语言"jcl"而不是单击的 GUI 或使用的 shell)和/或实际用 COBOL 编码的软件；维护了几十年的每个软件到处都有"特殊方式"，如果你遇到"实际上多年没有维护的十年旧代码"，你会遇到更多的麻烦/乐趣(这不是 COBOL 特有的，但是使用 COBOL 你可能会更频繁地遇到这个软件)。
不，没有什么能阻止互操作性。
Fortran 似乎有更多开箱即用的互操作的主要原因(这是一种观点，不是基于已知事实)是有一个免费软件 GNU/Fortran 供感兴趣的各方使用。 COBOL 在获得可行的自由软件编译器的过程中很晚。这不再是 GnuCOBOL 的问题，人们终于开始编写赶上所需的代码。
补充西蒙的答案；直接嵌入的概念证明在 GnuCOBOL 的一个分支中；到目前为止，已添加内部函数以支持 FUNCTION TCL、FUNCTION PYTHON、FUNCTION REXX、FUNCION LUA 和 FUNCTION JVM。使用针对 Scala、Groovy、Java、Frink 的 FUNCTION JVM 测试，一切正常。这允许使用简单的 COBOL 语法在 COBOL 工作存储和其他语言引擎之间传输数据。包括往返回调的设置。使用该分支时，这些函数会嵌入到编译器和 libcob 运行时。
对于其他接口试验，编译器没有内置，但仍然允许互操作； GnuCOBOL FAQ 有几十个例子。莎士比亚？是的。鹘？是的。 C，好吧，GnuCOBOL 发出中间 C，所以它被黑桃覆盖了。还有一个 C 版本的编译器，所以 C 也被涵盖了。 Javascript； Jsish、Duktape、Spidermonkey、Quickjs 等等。
Ada、D、Vala、Genie、S-Lang、ROOT/CINT、J、Gambas、Forth、Perl、Postscript、Pure、Icon 和 Unicon、Nim、BaCon、SWIG(打开多个倍数)、PARI/ GP、Gretl、R、Red、Ruby、Haxe/Neko、Pascal、Erlang、Elixir、SQLite、Rust、Go 等等，包括相当数量的 esolangs 和 GNU Lightning，用于运行中的组装模块。 GnuCOBOL FAQ 中记录的试验。
用于 AWT/Swing、GTK、Agar 以及 ZeroMQ、CGI 和 websockets 之类的框架接口也被证明是成功的，并且已投入生产使用。连同至少 7 个 EXEC SQL 预处理器已成功测试并正在使用中。
这取决于有人愿意尝试，并编写一些胶水或正确对齐调用框架。我尝试过的所有尝试都未能产生令人满意的结果，尽管 Perl 5 是一个解开宏层的头发拉。 (好吧，我只是撒谎了，在尝试嵌入 jq 时，它依赖于使用 C 调用并通过结构功能返回，我不得不离开纯 COBOL 接口编码，并且不打扰会实现它的 C 中间件简单)。 ;-) 不过总有一天会这样做，因为 jq 是非常强大的小型 JSON 处理程序。
使用您最不信任的搜索引擎并查找"gnu-cobol-builtin-script"和"GnuCOBOL FAQ"，然后访问 SourceForge 上的热门内容。
在我的特定探索中，我通常关注具有 C 应用程序二进制接口的语言，但其他 ABI 也会遵循类似的思路。只需坐下来编写一些中间件或弄清楚如何正确同步调用帧。
这些当前的样本是否完美？并非总是存在某些数据类型和 COBOL PICTURE 数据需要更多工作的边缘和角落情况，但仅此而已；一些工作和测试以消除颠簸。在探索时，我并不总是走那么远，直到出现实际需求。这些种子工作实验只是为了在布丁中获得一些证据，所有这些都是为了它的简单乐趣而完成的。
GnuCOBOL 的主要开发人员之一刚刚使用简单的文件名添加了单向和双向管道，它使用基本的 COBOL OPEN/READ/WRITE/CLOSE(和其他文件 IO)语句提供对基本操作系统提供的任何内容的访问。在我开始输入此响应之前的几个小时，代码已提交到主干。
基本上，这个问题的答案是响亮的。
政府系统中涉及的场景很可能是带有 z/OS、z/VSE 或 z/VM 操作系统风格的 IBM 大型机硬件。
这在一定程度上取决于互操作性的含义，因为大多数现代大型机都支持 TCP/IP，并且几乎将整个网络计算生态系统开放给网络互操作性。
我的猜测是，说到底，出现问题的原因是国家拒绝为有经验的大型机开发人员支付市场价格，并且已经将维护可以作为节省成本的措施。
这很可能不是没有大型机 COBOL 专业人员能够使系统正常工作的问题。国家很可能不会付出代价。
但这是我的猜测，因为我所知道的是state长将state IT 管理部门的拨款和管理失败归咎于无生命的物体。
作为一名拥有 40 年经验的大型机老手，我很想知道这个完美的技术是如何在处理(我再次假设)前所未有的处理需求量时出现问题的。
我们发现了 C 和 GnuCOBOL 之间的互操作性问题。
我们的问题已解决，因此此答案仅用于教育目的，以便您了解您可能遇到的问题类型。
当 C 调用 COBOL(a, b) 调用 C(c) 调用 COBOL(a, b) 时，问题就显现出来了。
特别是当参数的数量变化时。
最近对 GnuCOBOL 的更改假定 COBOL 称为 COBOL，因此它传递有关某个全局区域中参数的元数据。然后被调用的 COBOL 程序清除了第二个参数，因为错误地认为它是用一个参数调用的。也就是说，中间 C 调用对 COBOL 是透明的。
这是在使它与 IBM 大型机更兼容的幌子下，但它给我带来了很多悲伤。通过运行时更改快速解决了这个问题。我希望通过编译时选项来解决它：
顺便说一句：GnuCOBOL 很棒，而且背后有一个很棒的社区。如果您遇到问题，请报告它，您将获得比商业产品更好的响应。