我们有一个使用 CL 和 RPG 程序组合编写的存储过程。在 iSeries 上本地调用时一切正常。当从外部调用（例如从 SQL 前端）时，RPG 程序无法在它生成的假脱机文件上获得一个 hadle，因为假脱机文件出现在不同的（随机？）作业号和用户下。作业在 QUSRWRK 子系统中以 QUSER 身份运行，但假脱机文件获取连接池中外部建立连接的用户 ID（即 USERA）。
有没有一种方法能够在作业运行时可靠地获取正确的 sppol 文件的句柄（而不是依赖于从该队列中选择最后一个假脱机字段等）。
如果您正在运行存储过程（在作业 QZDASOINIT 中运行），您将无法通过程序状态数据结构访问假脱机输出。这些假脱机文件驻留在名为 user/QPRTJOB 的作业中，其中 user 是运行存储过程的“当前用户”。要访问假脱机文件，请运行 api QSPRILSP 以获取将您指向假脱机文件的结构。
IBM 的信息中心对行为和 API 都有很好的记录。
服务器作业（例如，用于 ODBC/JDBC 的数据库服务器实例）在系统用户配置文件下运行。对于存储过程，系统用户通常是 QUSER。在作业中创建的对象通常归作业用户所有。
服务器作业通常代表其他用户执行工作。您在建立连接时告诉服务器作业哪个用户。（请注意，在其生命周期内，给定的服务器作业可能代表许多不同的用户工作。）
特别是对于假脱机输出，这是一个问题，因为假脱机子系统的存在时间比我们拥有“Web”的时间还要长，并且在我们有大量用户连接到远程数据库之前。从一个用户切换到另一个用户的行为根本不是假脱机子系统构成的一部分，IBM 等供应商也无法确定假脱机文件何时应归特定作业用户或连接用户所有。（并且假脱机不是数据库连接的主要元素。）
IBM 确实通过默认“切换用户”输出收集到名为 QPRTJOB 的作业中来调整假脱机与用户相关联的输出方式，但它并不完全符合您希望以后的 RPG 程序处理输出的方式。
但是，如果您创建一个生成假脱机输出的存储过程，则该过程可以选择谁拥有输出，从而选择将其保留在同一个作业中。考虑这些可以粘贴到 iSeries Navigator 'Run SQL Scripts' 函数中的示例 CALL：
call qsys2.qcmdexc ('OVRPRTF FILE(*PRTF) SPLFOWN(*JOB) OVRSCOPE(*JOB)' , 48);
call qsys2.qcmdexc ('DSPMSGD RANGE(CPF9899) MSGF(QCPFMSG) OUTPUT(*PRINT)' , 51);
call qsys2.qcmdexc ('DLTOVR FILE(*PRTF) LVL(*JOB)' , 28);
如果您将它们作为一组运行，它们会创建假脱机输出，显示 CPF9899 的消息描述的属性。如果您之后检查，您应该会看到 QUSER 现在拥有一个名为 QPMSGD 的假脱机文件，并且它驻留在处理远程数据库请求的 QZDASOINIT 作业中。在这种情况下，该作业中的 RPG 程序可以轻松找到“*LAST”假脱机文件。此外，如果您删除了第一个和最后一个 CALL，现在只运行中间一个，您应该会发现您拥有下一个假脱机文件。
（QUSER 是 IBM 的默认值。如果您的系统使用不同的用户配置文件，请将该用户替换为“QUSER”。）
推荐：
更改您的 SP 以在后台处理您需要在作业中捕获的输出之前发出适当的 OVRPRTF 命令，并在生成输出后发出 DLTOVR。
您可以使用与此处显示的命令类似的命令来创建测试过程。尝试不同的 OVRSCOPE() 设置和 FILE(*PRTF) 或专门命名的文件。此外，在覆盖命令之前和之后创建输出，以查看它们的行为有何不同。
请注意，服务器作业可能会在您的 SP 完成后处理不同的用户（或者稍后可能会在作业中调用不同的 SP），因此您需要确保 DLTOVR 运行。（这是保持它接近 OVRPRTF 的原因之一。）
我需要更多信息，但我会做一些假设。如果我假设错了，请澄清。
QUSRWRK 行为中的 QUSER 是正确的。您现在正在通过 SQL 服务器（或类似服务器）运行。所有连接都在这些设置下运行。
有几种方法。
1）假设这一切都在一项工作中运行。使用“*”作为工作信息应该可以。
2) 另一个选项是使用 RTVJOBA CURUSER(&ME)。当前用户是登录的人。在这种情况下 USER 将不起作用。
作业本身知道或可以找出（请参阅以前的答案），因此，如果所有其他方法都失败，请修改程序以将消息放置在提供所需信息的队列上。闲暇时读一读。
.