修改service program后程序无需重新编译的原因及相关技术问题

引用绑定（bound by reference）是不是调用程序无需重新编译即可生效变更的核心原因？ #

是核心原因，但存在前提限制。

• *拷贝绑定（bound by copy）*的场景下，模块（Module）的完整二进制代码会直接复制到最终的程序对象中，模块逻辑修改后，必须重新绑定编译程序对象才能把新代码同步进去。
• *引用绑定（bound by reference）*的场景下，程序对象里只会存储服务程序的引用标识，不会拷贝服务程序的代码，程序运行时才会加载当前系统中最新的服务程序代码执行。
• 注意：只有服务程序的变更不涉及对外暴露的调用接口兼容问题时，才不需要重新编译调用程序。如果修改了原有导出 Procedure 的参数、返回值，或者删除了原有导出项，调用程序还是需要适配修改后重新编译。

仅持有服务程序的引用，是否属于动态绑定？ #

不属于通常意义上的动态绑定，它属于静态绑定的延伸范畴：

• 常规动态绑定是指程序完全在运行阶段才完成符号解析、目标实现加载，甚至可以在不修改程序本身的前提下随意替换实现逻辑。
• 服务程序的引用绑定在调用程序创建阶段就已经完成了导出符号解析，提前确定了要调用的服务程序名称、对应导出项的定位规则，运行时只会加载固定名称的服务程序，还要校验签名匹配，不允许随意替换不兼容的实现。
• 如果要实现完全的动态绑定，需要手动调用Qp0zDlOpen这类动态加载API，运行时主动加载服务程序、查找导出符号后再发起调用。

服务程序签名（signature）的相关规则是什么？什么情况下会发生变更？ #

基础规则 #

签名是服务程序的接口兼容性标识，本质是按规则生成的哈希值，会同时存储在服务程序本身和所有调用它的程序对象中，调用前系统会校验二者的签名是否匹配，不匹配会直接抛出MCH4403错误阻止运行。

• 默认创建服务程序时（参数SIGNATURE(*GEN)），签名由系统自动生成，生成规则基于当前所有导出项（Procedure、导出数据）的顺序、名称、类型计算哈希值。
• 也可以通过绑定源（Binder Source）手动指定固定签名，在绑定源中添加SIGNATURE '自定义固定签名值'指令即可，只要不修改这条指令，签名就不会发生变化。

签名变更场景 #

• 自动生成签名的场景：任何导出接口的变动都会触发签名变更，包括新增/删除导出项、调整导出项的排列顺序、修改原有导出项的接口定义。
• 手动固定签名的场景：只有主动修改绑定源中的SIGNATURE指令值，或者创建/更新服务程序时指定了新的签名参数，签名才会发生变更。

内容的提问来源于stack exchange，提问作者MordernRPGSoldier