我是第一个将SRVPGM引入我们的应用程序的人。在我的SRVPGM中，我在全球范围内定义了几个必要的文件，因为我们每天大约有5万笔交易，每个交易将调用10次子过程。虽然这些子过程由批处理作业和内部作业共享使用，但为了减少文件锁定，如果没有打开，我会打开相关子过程中的文件(使用%open)，并在从子过程返回之前在inter作业模式下关闭文件。
不幸的是，我们的用户界面输入程序是带有RCLRSC的OPM。我发现每次我退出界面并再次登录时，SRVPGM都会出现hv问题：在文件读取子过程中，%open返回1，但当链接/读取文件时，系统会提示"尝试引用已不存在的对象的全部或部分。"。我甚至尝试删除对%open的检查并直接打开(e)问题仍然存在。
我搜索了几篇讨论同一问题的文章，但仍然找不到首选的解决方案。
我们现有的(>1k)pgm几乎都是*DFTACTGRP。
我们与RCLRSC有许多pgm，我的项目预算无法支付研究和移除/更换RCLRSC的费用。
OVRDBF/OPNQRIF中有更多的pgm没有指定开放范围，所以我不能简单地将我们的pgm更改为名为ACTGRP的。
那么我接下来可以考虑什么呢？以下方法能解决我的问题吗(不过我现在仍在测试)
-
如果我只是保持文件打开直到INTER作业结束，因为我们的SRVPGM只读取文件？
-
如果我定义了两组文件读取子过程，一个是全局定义的用于批处理作业的文件，另一个是本地定义的用于INTER作业的文件？
-
放弃SRVPGM，只需将模块绑定到每个调用程序(aound 70，仍然可以管理)？
将RCLRSC与服务程序和ILE过程一起使用充其量是有问题的。RCLRSC是一个严格的OPM工具，在激活组存在之前的日子里，在现代机器上只影响默认的激活组，但它不会完全清除或结束它。RCLRSC只关闭文件并结束用DFTACTYGRP编译的程序(*YES)。如果选择DFTACTGRP(*NO)，RCLRSC不会触摸它。
下一个问题是，在使用DFTACTGRP编译的程序中不能使用子过程(*YES)。这是因为IBM不希望ILE过程在默认激活组中运行。这是可以做到的，但前提是你要小心，RCLRSC将是一个问题，正如你所看到的。文件已关闭，但ILE程序对象不知道这一点，因为激活组尚未结束和清理。此外，不鼓励通过指定ACTGRP(*CALLER)强制ILE过程在默认激活组中运行，因为在不结束作业的情况下无法完全关闭默认激活组。
如果您的OPM代码加载了无法修正的RCLRSC命令，那么您最好避免执行子过程。但最好的方法是删除RCLRSC命令。