我之前在项目里碰到过几乎一模一样的情况，结合DB2 for z/OS的权限机制和.NET驱动的特性，给你几个针对性的排查和解决方向：

1. 确认包权限的完整性——不止是EXECUTE权限 #

虽然你已经给用户授予了NULLID.SYSLH200的执行权限，但DB2 for z/OS的系统包有时候需要额外的绑定相关权限。可以尝试给用户添加BINDADD权限（如果环境允许的话），或者检查授权语句是否覆盖了正确的包范围：

GRANT EXECUTE ON PACKAGE NULLID.SYSLH200 TO USER_NAME;
-- 可以先尝试授予PUBLIC权限做测试（不建议生产环境长期保留）
GRANT EXECUTE ON PACKAGE NULLID.SYSLH200 TO PUBLIC;

另外要确认该包的状态是否正常，在DB2命令行执行以下查询：

SELECT COLLID, NAME, VALID, OWNER FROM SYSIBM.SYSPACKAGE WHERE NAME = 'SYSLH200' AND COLLID = 'NULLID';

确保VALID列的值为Y，如果是N，需要先重新绑定该包。

2. 检查C#连接字符串的配置细节 #

IBM.Data.DB2驱动的连接字符串可能会影响包的查找逻辑，建议你显式指定包集合和当前模式：

string connectionString = "Server=your_zos_db2_host:port;Database=your_db;Uid=USER_NAME;Pwd=your_password;PackageCollection=NULLID;CurrentSchema=your_target_schema;";

重点是PackageCollection=NULLID这一项，它会强制驱动使用NULLID下的系统包，避免因默认集合配置错误导致找不到已授权的包。

3. 验证驱动版本与Z/OS DB2包的兼容性 #

你使用的驱动版本是4.19.56，SYSLH200是对应特定驱动版本的系统包。要确认Z/OS上的NULLID.SYSLH200包和该驱动版本匹配。如果版本不兼容，即使授权正确也会报错。

可以尝试手动绑定驱动对应的包到Z/OS DB2：

• 找到IBM.Data.DB2驱动安装目录下的绑定文件（通常在\IBM\IBM DATA SERVER DRIVER\bind路径下）
• 使用DB2绑定工具（db2bind）执行绑定操作，指定NULLID作为集合：

db2bind db2cli.lst -d your_db -u USER_NAME -p your_password -r NULLID

绑定完成后，再次确认用户对这些绑定后的包拥有EXECUTE权限。

4. 排除代码执行上下文的问题 #

检查C#代码中是否存在以下情况：

• 是否在连接建立后切换了用户身份（比如使用SET USER语句）
• 是否使用了代理用户或应用程序角色，导致实际执行权限并非你授予的USER_NAME
• 是否在查询中隐式调用了其他系统包（复杂查询可能依赖额外的系统包）

可以先在DB2命令行工具中用同一个USER_NAME执行测试：

EXECUTE PACKAGE NULLID.SYSLH200;
-- 再执行你的目标查询
SELECT * FROM your_target_table WHERE ...;

如果命令行执行正常，说明问题出在C#驱动的配置或代码逻辑上，而非DB2权限本身。

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