ibm-midrange - 如何避免服务程序中意外的过程名称冲突？

Question

使用从著名的 IBM Red Paper on RPG Exception and Error Handling 中学到的概念，我写了一个服务程序QGPL/ERRFUNC实现可重用的错误函数，如 Assert , Throw , ThrowMsg , Rethrow , 和 GetErrorMsg .我一直在几个不同的程序中使用这些，并且它们运行良好。

刚才，我用了Throw RPG ILE 程序中的函数，该程序也静态调用 C 样式函数 access与 IFS 文件系统上的流文件一起使用。该程序将不会编译并出现“为符号抛出多次提供定义”的绑定(bind)错误。据我所知，使用 CRTBNDRPG 编译时无法获取绑定(bind)详细信息。命令，但我能够注释掉我的 H DFTACTGRP(*NO) spec 然后使用 CRTRPGMOD 编译它其次是 CRTPGM使用附加参数 DETAIL(*EXTENDED) .这会打印出编译器在确定要静态绑定(bind)到哪些过程时查看的所有过程名称的广泛列表。这揭示了“ throw ”的双重定义。在 72 页列表的深处，IBM 提供的服务程序 QJVAJNI (Java Native Interface) 被引用，它包含一个也名为“Throw”的导出过程。

现在，解决我眼前问题的最简单方法是简单地重命名我的“Throw”程序，修改并重新编译我的服务程序，然后修改并重新编译所有引用它的程序。我可能会遵循该解决方案，但这种行为引发了几个令人不安的问题:

为什么 C 风格的 IFS 函数使用 Java native 接口(interface)来完成它的工作？我看到像 QC2IFS 这样的服务程序的导入和 QC2POSIX这在上下文中完全有意义。看起来 IBM 在这里引入了一个我们必须忍受的意外依赖。我确定它是引用 QJVAJNI 的 C 服务程序之一。因为当我注释掉 access函数调用，QJVAJNI没有被引用。可能是对 QJVAJNI 的引用服务程序有好几层深，意思是导入一个导入一个导入。

为什么binder 会通过服务程序导入如此彻底地递归？活页夹看起来像是经历了每个服务程序使用的每个导入，无论该导入是否被程序和被绑定(bind)的子过程使用。那有必要吗？仅递归检查在每个级别使用的导入是否有效？有没有办法改变这种行为？

如果对上述两个问题无能为力，那是否意味着要保证绑定(bind)始终有效(尤其是对于错误处理等“通用”功能)，必须确保没有任何其他导出过程机器上的任何地方 同名？我不知道有任何像命名空间这样的工具可以缓解这个问题。据我所知，ILE 编译器不使用其他平台在这种情况下可能使用的任何方法，例如重载或名称修改。像我在某些 C 导出(例如 _C_NEU_IFS_feof )上看到的那样开始“非正式命名空间”以防止名称冲突是一个好习惯吗？或者，有没有办法在发布服务程序之前搜索机器上所有导出的程序以查找您想要的名称？

IBM 红皮书的作者是 ILE 编程领域的一些重量级人物。他们像我一样将他们推荐的导出之一命名为“Throw”(尽管使用了不同的参数列表)。他们遇到过类似的问题吗？他们是否有不同的方法来解决名称冲突？

我发现有一个选项 *DUPPROC可以指定为 CRTPGM ，但我不确定这是个好主意。文档说“当允许多个重复程序时，指定模块和服务程序列表中与导入请求匹配的第一个导出程序是选择的程序。”你能确定哪个符号将在列表中排在第一位吗？顺序是否严格定义？

Answer 1

RPG 或 C 中没有命名空间。绑定(bind) ILE 程序时，绑定(bind)目录控制使用哪些服务程序(和模块)来解析名称。它不是系统上的每个服务程序。但是也有一些默认绑定(bind)的服务程序，如果你使用这些自动绑定(bind)的服务程序之一导出的名称，你会遇到重名的问题。你说得对，*DUPPROC是个坏主意。在自动绑定(bind)的服务程序中处理与过程重复的名称的唯一方法是不使用这些名称定义新过程。有些人使用伪命名空间技术，如 serviceprogramname_procedurename或 applicationprefix_procedurename在命名他们的程序时。其他人只是通过其他方式确保他们的过程具有唯一的名称。但是在 RPG 支持某种形式的命名空间之前，您将不得不使用某种任意命名方案来确保过程名称的唯一性。

顺便说一句，在 developerworks 有一个 RFE向 RPG 添加命名空间。您需要登录到 developerworks 才能使用该链接，但您可以免费注册。然后访问RFE并投票。