从this的堆栈溢出问题中我了解到，一次发送一个batch（在此讨论中没有麻烦的管道），这意味着直到发送第二个batch为止第一个已交付。
我的后续问题是，什么情况开始batch creation process。如果我正确理解（显然我可能是错的...。），则会创建/剪切一个batch，或者如果{{{ 1}}或batch creation process或BATCHSZ reached或BATCHLIM reached，但以BATCHINT (=/=0) reached开始。 XMIT-Q is empty是与批量传输同步还是异步？ batch creation process是否仅在交付前一批次（同步）之后才开始，还是与前一批次完全脱钩（例如，当前一批次仍在传输时）？
这是1的同级/后续问题。目的是估计我们的QRepl-MQ转移上限。正如1中第一个（自我）答案中条目“ [12月20日添加]”中所述，我们的观察似乎支持batch creation process在先前的批量传输完成后同步启动。找不到记录详细信息的ibm参考资料……
感谢您的帮助。
答案 0 :(得分：1)
我们的观察似乎支持批量创建过程的开始 先前的批次传输完成后同步进行，但是我 找不到记录详细信息的ibm参考。
是的，它是这样工作的。如果第二批处理在第一批处理之前开始，则新消息会跳到旧消息之前，这可能会导致各种问题。
是的，我知道，应用程序不应该依赖于以逻辑顺序（即1,2,3等）出现的消息，但是它们确实如此。
想想MCA（消息通道代理），它是在黑色星期五从XMIT获取消息的过程，就像在商店的保安人员一样。他让50人排成一行（批次）。许多人离开商店后，他又让50个人进入商店。您是否要在商店中对生产线进行ASYNC批处理-绝对不是。保安人员希望命令不会混乱。
MQ的MCA也是如此。它创建一批“ n”条消息，发送它们，确认它们，然后转到下一批。