CICS/MQ触发器接口提供了一个简单方法，在无需编写代码的情况下驱动在线消息，但在有些情况下，这种简单的方法也让人感到很讨厌，本文讨论适用于IBM CICS Transaction Server 4.1和WebSphere MQ接口的消息触发。

　　消息触发器接口

　　CICS/MQ消息触发器接口始于事务CKTI，CKTI启动一个侦听队列（INITQ），当一个CICS绑定消息抵达时，MQ会通过INITQ发送一个消息唤醒CKTI，然后由CKTI读取触发消息，启动目标事务，提交工作单元，然后又从INITQ中删除触发消息，最后，CKTI尝试从INITQ中获得下一条消息，如果没有新的消息，它就开始转入随眠状态。

　　应用程序事务有两种触发方法：“在第一个触发”，当有一个应用程序消息抵达空队列后创建一个触发器；“每一个都触发”，每条消息抵达队列时都发送一个触发。
　
　　CICS/MQ触发问题：“遗留”消息

　　在这种情况下，一条触发消息唤醒CKTI，CKTI启动目标事务，然后同步点功能，最后删除触发器。目标事务启动读取它的预期消息，然后发送一个ABEND或ROLLBACK命令，如果应用程序队列定义为可回收，MQ将应用程序消息重新入队列。

　　至此，原始应用程序消息在队列中，而附加触发消息已经先行一步，在这种情况下，队列中的消息将会失去活力，直到其它触发器产生新的消息，实际上，这种情况将会持续下去，CKTI每接收到一个新消息，就将前一个消息推出队列，一直这样处理，直到队列中的消息变为零。

　　这个问题很难进行诊断，因为大部分监视器不支持测量花在队列等待上的时间，此外，虽然客户端报告响应时间较长，但CICS监视器却显示没有问题，一个可行的线索是非零队列深度，尽管这可能是应用程序的正常行为，有关完整的诊断，技术支持可能已找到某些处理办法，可能出在消息数据本身，因此需要跟踪从客户端到CICS的请求及相反方向的响应数据。

　　这种情况的严重性取决于应用程序的数量和重要性，如果应用程序没有时间依赖性，为下一条消息抵达等待五分钟并不会有什么害处。但是，如果队列中的部分消息在等待响应，等待将是致命的。

　　绕过“遗留问题”最好的办法可能是修改应用程序，允许一次读取多条消息，获取过去无触发器的消息，然而，找到正确数量的消息同时读取可能是一个棘手问题。

　　工作量平衡的神话

　　MQ支持共享队列，它将消息存储在Sysplex耦合体（Coupling Facility，CF）中，任何应用程序都可以从这里读取消息，INITQ的消息也可以共享，它将触发消息放入CF中，MQ然后唤醒每个CKTI监听器，为每个要获得的触发器创建一个比赛，再启动目标事务吃掉消息完成整个过程，CKTI剩下的任务就是返回并自我休眠。

　　注意，在这种方案中没有内置工作量平衡机制，在克隆的CICS实例间共享INITQ时，预期工作将会被顺利分配，注意克隆实例是在相同的处理器上以相同的优先级运行的。

　　根据我以往的经验，时间间隔通常是五分钟或更长，但在较短的时间间隔下，有时监听器会赢得比赛，会成功读取到触发消息，因此，CICS可能在短时间内没有几百，也有几十条消息从队列消失。

　　再说一次，这与应用程序有很大的关系，少部分无时间依赖的应用程序可以提供一些控制，如事务类应用缓存某些突发性的冲击，而严重依赖时间的应用程序可能需要寻求其它形式的补救。

　　IBM将会告诉你，那纯粹是一个竞争条件，没有任何类型的智能控制工作量分配。每个人都喜欢胜利者和MQ，这里显然也不例外，如果事务类或其它CICS抑制机制不能工作，最好的解决方案是事务路由，CKTI运行在路由区域，它可以跨应用程序组拥有的区域或AORs分散目标事务。

　　小结

　　上述问题在MQ接口中是一直存在的，必须得到妥善处理，最好的防御是根据一些建议精心设计应用程序，首先，IBM建议大部分队列应该定义为“第一个触发”，其次，应用程序应该一次读取多条消息，避免被卡住，最后，应该尽量使用可回收队列。