SBMJOB提交excextfun程序时内部调用是否可访问同一QTEMP库

首先明确IBM i平台的QTEMP基础机制：QTEMP是作业级隔离的临时库，每个独立作业拥有专属的QTEMP实例，仅当前作业内运行的所有程序可访问，同作业内程序不存在跨程序访问QTEMP的权限问题。你遇到的交互运行正常、SBMJOB提交后报表无数据，本质是批作业和交互作业的运行环境差异导致QTEMP的数据写入逻辑未正常执行，和QTEMP访问权限无关。

• 库列表不一致：交互作业登录时会加载用户配置的完整库列表，包含业务数据所在的生产/测试库；SBMJOB提交作业时如果未显式指定初始库列表，会默认读取关联作业描述（JOBD）中配置的库列表，大概率缺失业务库路径，导致后续数据抽取程序找不到源表，写入QTEMP的数据为空，最终报表无数据。
• 文件覆写作用域不匹配：你提到QTEMP的文件覆写操作在excextfun程序内完成，默认OVRDBF/OVRPRTF命令的覆写作用域和激活组绑定，如果被调用的抽取程序运行在独立命名激活组，会无法识别当前程序配置的QTEMP覆写规则，直接读写原库文件而非QTEMP中的临时文件，导致QTEMP中无有效数据。如果覆写后执行过RCLRSC资源回收操作，也会直接导致未指定作业级作用域的覆写规则失效。
• 初始化逻辑依赖交互环境：部分QTEMP临时表创建、基础参数初始化的逻辑写在用户登录初始化程序（INLPGM）中，SBMJOB提交的批作业默认不会执行用户登录初始化流程，会导致QTEMP中缺失必要的临时表结构，后续抽取程序写入数据时报错被静默捕获，无有效数据写入。部分老程序还会内置作业类型判断逻辑，检测到是批作业（作业类型为BATCH）时直接跳过数据抽取步骤。
• 运行身份权限差异：交互模式下程序用当前登录用户权限运行，通常拥有业务表查询权限；SBMJOB如果未显式指定运行用户，会默认使用关联JOBD中配置的用户运行，若该用户缺少业务源表的查询权限，抽取程序无法读取数据，写入QTEMP的内容自然为空。

• 先开全量作业日志定位问题：提交SBMJOB时显式指定参数LOG(4 00 *SECLVL) OUTQ(你的个人输出队列)，作业运行结束后直接查看作业日志，排查是否存在文件未找到、权限不足、覆写未生效的报错，绝大多数场景可以通过日志直接定位根因。
• 统一文件覆写作用域：所有excextfun程序内指向QTEMP的OVRDBF/OVRPRTF命令，统一添加参数OVRSCOPE(*JOB)，确保同作业下所有程序无论运行在哪个激活组，都能识别到QTEMP的文件映射规则，避免覆写失效。
• 显式对齐批作业运行环境：SBMJOB提交excextfun时，显式指定INLLIBL参数为交互模式下的完整用户库列表、CURLIB参数为交互模式下的当前业务库、USRPRF(*CURRENT)参数确保用当前提交用户的权限运行，不要依赖JOBD的默认配置，从根源消除环境差异。
• 校验程序分支逻辑：检查excextfun及后续调用的抽取程序代码，排查是否存在通过RTVJOBA获取作业类型、批作业场景下跳过QTEMP写入的分支逻辑，调整逻辑保证批作业下数据抽取流程正常执行。
• 快速验证技巧：可以在excextfun程序入口加一段调试逻辑，将当前作业的库列表、运行用户、作业类型、QTEMP下存在的对象列表写入固定库的调试日志表，对比交互运行和SBMJOB运行的日志差异，可快速定位不一致的配置项。

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