降低 COBOL 与其他语言进行交互时产生的性能影响简介

look_w

简介几十年前，当我初次开始使用大型机 COBOL 时，我发现它不能与非 COBOL 语言交互。我与一位教授探讨将这作为一个论文题目，主要探讨让 COBOL 与非 COBOL 语言进行交互所产生的性能影响。  
为了弄明白可能会有什么性能影响，我基于 “A Fortran Interface to the CODASYL database task group specifications”（参阅 ）试验开发了小型 COBOL/Fortran 接口。Fortran 是当时非常流行的一门语言。
我注意到，一些 COBOL 数据类型在 Fortran 中没有等效的数据类型。不再需要的数据或对象仍然在磁盘上。我看到，当分配的内存超过所需内存时，就会出现堆栈溢出的迹象。我使用正确的 Fortran/COBOL 数据类型解决了这些问题。我在需要时调用子程序，并在不需要时释放它们，以这种方式规避内存限制。当时处理器的容量上限很低，无法与我们今天看到的大容量处理器相比。
在本文中，我会给出一些提示，教您如何避免在 COBOL 与 Java、C/C++、DB2 和 Oracle 进行交互时被动受制于其性能影响。

• 避免超时
• 使用编译脚本
• 遵循数据转换规则
• 预防内存泄漏
• 删除本地引用

接口性能影响：Java 与 C/C++在我第一次使用 Fortran 时，它已广泛流行于计算界。如今，Java® 是继 C/C++ 之后最流行的语言，可作为与 COBOL 交互的接口。Fortran 目前深受科学家喜爱，但在普通人群中的流行度则有所下降。  
使用 Java 作为接口您可以让一个 COBOL 程序调用一个 Java 程序，而后者会调用一个不同的 COBOL 程序。如果在设计 Java 程序时不够谨慎，您可能会遇到导致性能影响的内存问题。这些问题包括内存泄漏、高内存使用率、无效对象创建和无效的垃圾收集器行为。其他一些性能问题包括跟踪对象本地引用和在线程中使用本地引用所产生的问题。
Java 中的内存泄漏是由于引用不再需要的对象而产生的。高内存使用的一个来源是低效配置的缓存和并行访问系统的大量活动用户。
当用户负载增加时，无效对象创建会变得很明显，因为垃圾收集器必须不断清理堆积物。这可能导致垃圾收集器具有较高的处理器消耗。当垃圾收集器配置不当时，会发生无效的垃圾收集器行为。   
仅当您调用的方法处于运行状态时，对象的本地引用才是有效的。本地引用的自动释放并不总是发生在本地方法返回之后。在显式删除全局引用之前，它们仍然是有效的。当您尝试从一个线程向另一个线程传递本地引用时，本地引用会变得无效。为了确保没有在垃圾收集过程中过早释放对象，Java 虚拟机 (JVM) 会跟踪本地和全局引用。
如果没有显式释放本地引用，系统会在以下两种情况下耗尽内存。  

• 情况 1：您在一个方法中访问一个大型对象，以创建对象的本地引用，将它们用于大量计算。本地引用预防在垃圾收集过程中释放该对象。
• 情况 2：您没有同时使用一个方法中创建的所有本地引用。在一个 COBOL 方法中，您对一个大型对象数组执行循环，获取元素作为本地引用，并在每一次迭代时对元素进行操作。在每一次迭代之后，不会自动释放对数组元素的本地引用。

使用 C/C++ 作为接口在一个 C/C++ 程序中，当调用堆栈上使用了过多内存时，就会发生堆栈溢出。堆栈上分配的内存比实际需要的多。回调中的堆栈大小取决于系统架构和可用的内存量。
降低一个给定 C/C++ 程序的有效堆栈大小之后，堆栈溢出情况会更加严重。如果在多线程模式下运行程序，与没有线程支持或分配给单一线程的程序相比，具有多线程的程序每个线程具有更少堆栈空间。
在 COBOL 与 C/C++ 程序之间的调用中，当您尝试调用使用一种语言的函数、而该函数会破坏另一种语言的程序堆栈框架时，就会出现性能问题。对于不会导致有效堆栈框架崩溃和终止的语言，不利影响可能会导致堆栈溢出。
例如，可能无法执行语言的正常清理或退出功能，比如使用 COBOL 在运行单元终止过程中关闭文件，使用非自愿终止的语言清理动态获取的资源。  
接口性能影响：IBM DB2 和 OracleIBM COBOL for AIX® 与 IBM DB2® 软件一同使用，并且可以与 Oracle 客户端和运行 Tuxedo 的 Oracle 客户端进行集成。执行嵌入式 SQL 语句的 COBOL 程序通过一个名为 SQL Communications Area (SQLCA) 的工作存储区域与 DB2 和 Oracle 进行通信。在运行 SQL 语句之前，系统会检查权限和角色，核对主键并查询外键。它还会检查约束和索引，执行复杂的优化器和事务控制。系统会执行锁定、记录、提交和回滚操作。
不更改默认值或不当配置任何默认值都有可能导致 SQL 执行失败。操作的所有结果都返回到 SQLCA 中的 SQLCODE 和 SQLSTATE 字段中。SQLCODE 提供了有关 SQL 语句是否成功执行的重要信息。  
长时间等待锁超时的一个原因是，对象被另一个用户锁定，或者锁定在另一个会话中，但是应用程序没有检测到该锁定。应用程序等待访问该对象，直至因 DB2 超时而中断。
如果在尝试访问或编辑一个对象时没有更改 LOCK TIMEOUT 的默认值 -1，就不会有锁超时设定。如果在一个 SQL 嵌入语句中使用 SET CURRENT LOCK TIMEOUT 将时间设置为超过 10 秒或 15 秒，就会产生较长的超时延迟。
长时间等待锁会对锁产生不利影响。您会变得不耐烦。如果当前工作单元回滚，您会为此而烦恼。这一失败操作的结果被返回到 SQLCODE 中。
例如，SQLCODE = -901 表示锁超时错误，并且已经为 LOCKTIMEOUT 设定了一个值。SQLCODE = -911 表示有死锁/超时，且执行了回滚。SQLCODE = -913 表示有死锁/超时发生，但没有执行回滚。
SQLCODE 是程序的 WORKING-STORAGE SECTION 或 LINKAGE SECTION 中的 SQLCA 记录的一部分。更易于将 SQLCODE 添加到 sqlca.cbl。这个样例程序是 checkerr.cbl 的 LINKAGE SECTION 的一部分，checkerr.cbl 是使用 AIX 脚本 (bldapp) 构建的 COBOL 应用程序中的一个 DB2 错误检查实用程序。
高内存需求在嵌入式 COBOL 语句中，存储过程较动态 SQL 提供了很多优势，其中包括改进的性能和可扩展性。存储过程被优化且以本机语言优化的形式保存。在调用存储过程时，一切准备就绪。当您发送一个 SQL 语句时，查询处理器必须解析它，分析它，然后创建一个要执行的查询计划。
不过，这样做有一个缺点。调用存储过程可能有更高的内存需求。如果这些需求过高，SQL 执行就不会成功。