我们有一个进程，每当我们关闭iSeries服务器时，它都会定期运行。它执行以下命令（特定于 iSeries，但您可以知道 MQSC 命令是什么）：
RCDMQMIMG OBJ(*ALL) OBJTYPE(*ALL) DSPJRNDTA(*YES)
ENDMQMCSVR MQMNAME(IA001.QUEUE.MANAGER)
ENDMQM MQMNAME(IA001.QUEUE.MANAGER)
DLYJOB DLY(120)
ENDMQMLSR MQMNAME(IA001.QUEUE.MANAGER)
通常，这运行没有问题，但是在最后一次情况下，六个通道中有五个正常立即结束，第六个通道在大约 75 秒后异常结束。
从通道作业的日志来看，这两个消息是连续的（即没有干预问题）：
23/07/12 08:26:44.033529 LIBMQMCS_R QMQM *STMT QCMD QSYS 01C8
From module . . . . . . . . : AMQXEIMX_R
From procedure . . . . . . : xcsSendMessage
Statement . . . . . . . . . : 38
Message . . . . : Channel 'IA001.TO.ISPRO' is starting.
Cause . . . . . : Channel 'IA001.TO.ISPRO' is starting. Recovery . . . :
None. Technical Description . . . . . . . . : None.
04/08/12 21:11:28.872098 QWTPITP2 QSYS 061A *EXT *N
Message . . . . : Job ended abnormally.
Cause . . . . . : A SIGKILL signal was received for the job. The action for
the signal was to terminate the job.
请注意，ENDMQM 不使用 *WAIT 来等待队列管理器结束（默认的 *CNTRLD 正在运行），但我认为这在这种情况下没有帮助，因为我找不到任何证据表明任何其他进程可以停止程序。通道作业的强制结束发生在代码中手动插入的 120 秒延迟内（我知道，我们应该使用 *WAIT，但这段代码很旧）。
我认为假设通道在队列管理器结束时正在处理消息是合理的 - 否则为什么在下一个操作之前会经过 75 秒？似乎 *CNTRLD 选项有一个隐含的超时，尽管我在文档中的任何地方都看不到这个问题。要么是那个，要么是别的东西介入了。但是什么？
ENDSBS *ALL 确实遵循了，但我已经证明那是在频道死亡几分钟后。
这为以后创建的有趣场景是，当队列管理器重新启动时，发出了一个错误，指出通道已经在运行，但通道作业看起来与正常情况完全一样，在日志中显示"通道正在启动"，并且确实运行良好。
任何关于可能涉及什么外力或是否有超时的建议将不胜感激。
这有几个可能的原因。 该通道显示为出站通道，当 QMgr 关闭时，它可能处于阻止网络调用中。或者，它可以在批处理的中间并在另一侧等待响应。如果另一端暂停或连接断开，则通道在等待响应时可能会挂起。
如果侦听器仍在运行，则入站通道通常很难停止。 如果另一端有消息要发送并启用了触发，它将立即尝试重新启动通道。 此请求命中启动进程的侦听器。由于 QMgr 正在关闭，通道无法完成其CONNECT但会在短时间内运行通道进程。
无论是入站还是出站，QMgr 最终都会杀死不会自行关闭的进程。 这应该不是问题，因为通道将协商有序重启，尽管它确实会在日志中留下一些错误。
调整所有这些因素包括 TCP 保持连接、HBINT、DISCINT、通道重试参数和采用 MCA 参数。