我有一个用VB.NET 2.0编写的Windows服务，它连接到IBM AS / 400服务器。查询工作正常，但是当我尝试删除假脱机文件时，我会收到错误。例如：
CPYSPLF FILE(PO630A) TOFILE(MPLCDATPAR/PO630APF) JOB(083064/ARUSER/POASYNCMON) SPLNBR(80) MBROPT(*REPLACE)
使用ExecuteNonQuery运行此命令会产生：
CPF3342 - Job not found 083064/ARUSER/POASYNCMON
但是，如果我在AS / 400中本地运行相同的命令，它可以正常工作。我们已经检查了权限。还有什么可能导致命令以这种方式失败？如何获取有关错误的更多信息，或者对此进行故障排除？
编辑：当我们将服务器（运行.NET服务的地方）从Windows Server 2003迁移到Windows Server 2008时，会出现此问题（以及许多其他问题）。
答案 0 :(得分：1)
如何获取有关错误的更多信息，或者对此进行故障排除？
首先要验证 IBM AS / 400服务器 [什么操作系统版本发布和修改级别，技术更新（TR）级别（，而不是IBM i ），累计PTF级别全部省略。？。？]用于连接的是用于执行命令行调用的相同服务器;即，在将进行命令行调用以验证命令是否正常的服务器上，找到活动服务器作业，其中CPF3342仍在日志中可见。
要做的第二件事是让假脱机的joblog显示CPF3342的全部细节[以及可能相关的任何前面的消息]。例如，如果消息实际上不是该消息或预期程序QSPCPYF未发送消息，那么调查方向可能会立即改变。显示的内容显然是客户端呈现的内容，而不是来自服务器作业日志的内容;我认为USEnglish格式是“找不到Job＆amp; 5 /＆amp; 4 /＆amp; 3”。格式为“CPF3342 - 找不到作业＆amp; 5 /＆amp; 4 /＆amp; 3”的格式是可疑的。
确保与客户提出的请求进行最恰当的比较： •登录以执行相同请求的本地用户应与发现为客户端请求提供服务的活动作业的当前用户相同的用户 •本地用户应与发现为客户端请求提供服务的活动作业建立相同的系统库列表
如果此类事件再次发生或即使同一事件仍然存在，那么再次验证是否仍然可以使用相同的界面进行重新创建[即条件\失败仍然存在]并再次验证命令行请求是否成功[即确认规避，相同的请求可以在命令行执行];根据我之前的评论，首先通过查找记录CPF3342的活动作业来确保相同的服务器。紧接着：
•收集复制假脱机文件（CPYSPLF）请求的作业跟踪;对于失败的情况，检查在发布msg CPF3342的程序流程之前的任何异常\中断条件[有或没有作为伴随跟踪数据的消息]。
•在非常接近失败请求时查看任何T-AF或任何奇怪\意外的审核日志;应该在连接到服务器之前建立扩展审计。
•将失败案例的数据集与成功处理的相同数据进行对比。
尽管症状[如轻描述，没有完整的作业日志]命令退出的可能性似乎很远，但跟踪会显示任一场景中的命令是否被命令退出点截获;这些可以单独审查[而不是查看]任何退出程序，使用“使用注册信息”（WRKREGINF）查看存储库中的任何QIBM_QCA *条目，以了解哪些退出程序可能会影响CL命令请求。但是IIRC跟踪数据显示调用了哪个命令，因此跟踪还会显示非限定命令请求是否已解析为不同的* CMD对象。