我是第一个将SRVPGM引入我们的应用程序的人。在我的SRVPGM中，我全局定义了几个必要的文件，因为我们每天大约有5万笔交易，而子过程每笔交易被称为10倍。虽然批处理作业和内部作业都共享了这些子过程，但为减少文件锁定，我打开了相关子proc中的文件（如果未打开，请使用％open），并在从子proc返回之前以INTER作业模式关闭文件。
不幸的是，我们的用户界面输入程序是带有RCLRSC的OPM。我发现每次退出界面并再次登录时，SRVPGM都会出现问题：在文件读取子proc中，％open返回1，但是当链/读取文件时，系统提示“试图引用全部或部分内容一个不再存在的对象。”。我什至试图删除％open上的检查并直接打开（e），问题仍然存在。
我搜索了几篇讨论相同问题的文章，但仍然找不到首选的解决方案。
我们现有的（> 1k）pgms几乎都是* DFTACTGRP。
我们在RCLRSC上有很多pgms，我的项目预算无法涵盖研究和删除/替换RCLRSC的工作量。
还有更多的OVRDBF / OPNQRYF未指定开放作用域的pgms，所以我不能简单地将pgms更改为命名的ACTGRP。
那么我接下来可以考虑什么？以下方法可以解决我的问题吗（不过我现在仍在测试它们）
如果我只打开文件直到INTER作业结束，因为我们的SRVPGM只读取文件？
如果我定义2组文件读取子proc，其中一组为批处理作业使用而全局定义文件，一组为INTER作业在本地定义文件？
放弃SRVPGM，只需将模块绑定到每个调用程序（大约70，仍然可以管理）？
答案 0 :(得分：1)
在服务程序和ILE程序中使用RCLRSC充其量是有问题的。 RCLRSC从激活组甚至还没有存在的那一天开始就严格来说是一种OPM工具，并且在现代计算机上仅会影响默认的激活组，但是并不能完全清除或终止它。 RCLRSC仅关闭文件并结束用DFTACTYGRP（* YES）编译的程序。如果选择了DFTACTGRP（* NO），则RCLRSC不会触摸它。
下一个问题是，您不能在使用DFTACTGRP（* YES）编译的程序中使用子过程。这是因为IBM不希望ILE过程在缺省激活组中运行。可以做到，但是只有当您小心时，RCLRSC就会成为您所看到的问题。文件已关闭，但是ILE程序对象不知道该文件，因为激活组没有结束并没有被清理。另外，不建议通过指定ACTGRP（* CALLER）强制ILE过程在默认激活组中运行，因为您无法在不结束作业的情况下完全关闭默认激活组。
如果您的OPM代码中加载了无法修复的RCLRSC命令，那么您最好避免使用子过程。但是，最好的方法是删除RCLRSC命令。