使用JT400连接池调用IBM i RPG程序后，它们引用了错误的库

如何解决使用JT400连接池调用IBM i RPG程序后，它们引用了错误的库

我有一个Java应用程序，该应用程序调用CL程序，然后使用JT400库在IBM i系统上运行多个RPG程序。

首先，我每次都打开一个新的连接，就像这样，并在完成后将其关闭：

new AS400(hostname,username,password);

但是，由于连接数量的增加，我最近开始使用连接池：

@Bean
public AS400ConnectionPool as400ConnectionPool() {
    String hostname = env.getProperty("AS400Hostname");
    String username = env.getProperty("AS400Username");
    String password = env.getProperty("AS400Password");

    AS400ConnectionPool as400ConnectionPool = new AS400ConnectionPool();
    as400ConnectionPool.setMaxConnections(128);

    try {
        // preconnect 5 connections to the AS400.COMMAND service.
        as400ConnectionPool.fill(hostname,password,AS400.COMMAND,5);
    } catch (ConnectionPoolException e) {
        log.error(e.getMessage());
        e.printstacktrace();
    }
    return as400ConnectionPool;
}

每个连接现在都在使用后返回到池中，而不是被关闭。

不幸的是，我们开始看到以前运行完美的相同作业，有时在IBM i上进入MSGW状态。 （消息等待）

在分析作业日志时，我注意到以下类型的错误：

CPF4131在打开文件期间出现

大约同时运行来自两个不同库的作业时，似乎正在发生这种情况。 该程序通常同时具有与IBM i的大约10个开放连接，并且可能同时运行许多不同的作业，大多数作业来自同一库，而只有少数几个库位于不同的库中。 稍后再运行相同的呼叫将毫无问题。

我正在运行该程序的库似乎正在该程序未引用的其他库中查找文件。

例如以下CL调用：

致电pgm（ADDPRGXX / TESTCL）

最终将在随后的RPG调用中导致此类错误：

TESTRPG * INIT ADDPRGXX打开SOMEFILE CPF4131 对具有成员SOMEFILE的库ADDFILXS中的文件SOMEFILE进行级别检查。

＆N原因。 。 。 。 。 ：库ADDPRGXX中的RPG程序TEsstRG 对文件执行隐式OPEN时收到消息CPF4131 某些文件。请参阅作业日志以获取消息的完整说明 CPF4131。如果文件的设备类型为SPECIAL，则可能没有 作业日志中的消息。 ＆N恢复。 。 。 ：输入C取消，输入S到 获得系统存储的打印输出，D获得格式化的RPG 系统存储的打印输出，或按F获得完整格式的打印输出 系统存储。 ＆N回复消息的可能选择。 。 。 。 。 。 。 。 。 。 。 。 。 。 。 ：＆B D-获取RPG格式的打印输出 系统存储。 ＆B S-获取系统存储的打印输出。 ＆B F- 获取系统存储的全格式打印输出。 ＆B C-取消。

示例SOMEFILE在ADDFILXS中不存在，而仅在ADDFILXX中，程序调用中从未引用ADDFILXS。

CL程序首先添加必要的库，然后调用RPG，例如：

ADDLIBLE LIB(ADDPRGXX)
MONMSG MsgiD (CPF0000)
ADDLIBLE LIB(ADDFILXX)
MONMSG MsgiD (CPF0000)
CALL TESTRPG

是否需要在以后的RPG调用中使用一些对库的引用？ 或者，我应该对连接池做其他事情来防止这种情况吗？

我现在开始为每个库使用2个独立的池，这似乎正在工作。 但更希望找到根本原因并加以解决。

解决方法

我怀疑还有更多事情要做（或者您简化了示例）

示例SOMEFILE在ADDFILXS中不存在，而仅在ADDFILXX中存在

但是如果您要得到的话就不可能了

CPF4131对具有成员的库ADDFILXS中的文件SOMEFILE进行级别检查 某些文件

如果SOMEFILE实际上不存在，将会是一条不同的消息。

无论如何，有很多陷阱试图通过在工作生命周期中更改库列表来更改“环境”。由于您已经开始使用连接池，因此连接在IBM i端保持打开状态，因此操作系统在两次使用之间不会重置QZDASOINIT（或相关作业）。

您没有提到或不是在使用ILE或OPM程序。但是每个人都有自己的一套问题，如果将它们混合在一起，情况会变得更糟。 OPM CL调用ILE RPG。

最好的解决方案是您想到的解决方案，针对不同的环境使用单独的池。

不仅更安全，而且性能也会更好。

• 更改库列表不是“便宜”
• 允许程序保持活动状态，并打开数据路径保持打开状态。
• ILE激活组可以在作业中保持活动状态。