Ibm midrange RCLRSC使用F-spec crash制造SRVPGM

我是第一个将SRVPGM引入我们的应用程序的人。在我的SRVPGM中，我在全球范围内定义了几个必要的文件，因为我们每天有大约5万个事务，每个事务的子过程将被调用10次。虽然这些子过程由批处理作业和作业间共享使用，但为了减少文件锁定，如果未打开，我将在相关子过程中打开文件（打开百分比），并在从子过程返回之前在作业间模式下关闭文件

不幸的是，我们的用户界面输入程序是带有RCLRSC的OPM。我发现每次退出界面并再次登录时，SRVPGM都会出现问题：在文件读取子过程中，%打开返回1，但当链/读取文件时，系统提示“尝试引用不再存在的全部或部分对象”。我甚至尝试取消对%open和directly open的检查（e）问题仍然存在

我已经搜索了好几篇讨论同一问题的文章，但仍然找不到首选的解决方案

我们现有的（>1k）PGM几乎都是*DFTACTGRP

我们有许多带有RCLRSC的PGM，我的项目预算无法涵盖研究和移除/替换RCLRSC的工作

有更多的PGM使用OVRDBF/OPNQRYF不指定开放范围，因此我不能简单地将PGM更改为命名的ACTGRP

那么接下来我能考虑什么呢？下面的方法能解决我的问题吗（不过我现在还在测试它们）

如果我一直打开文件直到任务结束，因为我们的SRVPGM只读取文件

如果我定义了两组文件读取子过程，一组是为批处理作业使用全局定义的文件，另一组是为内部作业在本地定义的文件

放弃SRVPGM，只需将模块绑定到每个调用程序（aound 70，仍然能够管理）

---

将RCLRSC与服务程序和ILE过程一起使用充其量是有问题的。RCLRSC从激活组出现之前的几天起就是严格意义上的OPM工具，在现代机器上只影响默认的激活组，但它不能完全清除或结束它。RCLRSC仅关闭文件并结束使用DFTACTYGRP（*是）编译的程序。如果选择DFTACTGRP（*否），则RCLRSC不会触摸它

下一个问题是不能在使用DFTACTGRP（*是）编译的程序中使用子过程。这是因为IBM不希望在默认激活组中运行ILE过程。这是可以做到的，但前提是你要小心，正如你所看到的，RCLRSC将是一个问题。文件已关闭，但ILE程序对象不知道，因为激活组未结束和清理。此外，不鼓励通过指定ACTGRP（*CALLER）强制ILE过程在默认激活组中运行，因为在不结束作业的情况下无法完全关闭默认激活组

如果您的OPM代码中加载了无法修正的RCLRSC命令，则最好避免使用子过程。但最好的办法是删除RCLRSC命令