ILE概念中UPDSRVPGM与CRTSRVPGM的差异及UPDSRVPGM使用优势

两个命令都是IBM i平台ILE（集成语言环境）下操作服务程序（*SRVPGM，类似Windows下DLL、Linux下so共享库）的工具，但定位完全不同：

• CRTSRVPGM是从零创建的全量编译命令：执行时必须提供构成服务程序的所有模块（MODULE）、绑定目录、binder导出定义源等全量输入，运行后会生成全新的SRVPGM对象，如果指定的库/路径下已有同名对象会直接覆盖。
• UPDSRVPGM是面向已有对象的增量更新命令：不需要提供服务程序的全量构成材料，仅需要传入要替换、新增的模块或调整项，在原有*SRVPGM对象基础上做局部修改，不会重建整个对象。

全场景直接用CRTSRVPGM会踩非常多生产级的坑，核心问题集中在4点：

• 极易破坏签名兼容性：ILE服务程序靠生成的签名（signature）匹配调用关系，用CRTSRVPGM全量重建时，哪怕代码逻辑完全没改，只要编译时模块排列顺序、导出项顺序有微小变化，签名就会改变，所有已经绑定过这个服务程序的程序、其他服务程序运行时会直接抛出签名不匹配错误，业务直接中断。
• 丢失对象的非编译属性：原有服务程序上配置的对象权限、公共授权、审计规则、所有者信息、对象变更记录，在CRTSRVPGM覆盖重建后会全部重置为编译默认值，每次重建都要重新核对配置，漏配权限就会出现业务账号无法调用的问题。
• 编译效率极低：如果服务程序包含几十个模块、依赖十余个其他服务程序，哪怕只改了其中一个模块的单行逻辑，CRTSRVPGM也要重新完成全量链接绑定，大服务程序单次编译可能耗时数分钟到十几分钟，补丁迭代效率极低。
• 破坏运行中作业的持久状态：重建操作会清空对应激活组内该服务程序留存的静态变量、已打开的文件句柄、SQL预编译缓存，长驻运行的批处理、服务作业会直接出现内存访问错误、文件句柄失效问题。

UPDSRVPGM就是为了解决上述CRTSRVPGM的生产痛点设计的，独有价值集中在：

• 可控的签名兼容性：更新时可以显式指定签名参数为*SAME，只要没有修改对外暴露的接口定义，哪怕替换了内部实现模块，服务程序的签名完全不变，所有已绑定的调用方不需要重新编译就能正常调用，是ILE环境实现不宕机打热补丁的核心手段。
• 完整保留原有对象配置：更新操作不会修改服务程序的所有者、权限列表、审计规则、对象描述、域隔离配置，更新完成后不需要重新做配置核对。
• 增量更新效率极高：仅需要传入修改后重编译的少量模块，命令仅做增量链接，哪怕是包含几十个模块的大型服务程序，更新耗时通常也在数秒内，补丁上线窗口极短。
• 低依赖的灵活调整：不需要留存服务程序最初创建时的全量模块副本、完整binder源文件，就能完成模块替换、新增导出项、追加依赖服务程序的操作，老系统维护场景下尤其好用。
• 对运行中作业影响极小：只要保持签名兼容，已经加载了旧版服务程序的运行中作业可以继续执行原有逻辑，新发起的调用自动路由到更新后的版本，不需要强制结束所有关联作业就能完成版本更新。

注意：UPDSRVPGM不能完全替代CRTSRVPGM，如果要修改服务程序的核心激活属性、或者做了不兼容的接口变更（比如删除导出项、修改导出参数的类型/长度），还是需要通过CRTSRVPGM配合版本化的binder源做正式发布，避免出现隐式的兼容性问题。

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