大型机问题影响事务恢复
在某些情况下，TI 无法使用远程环境处理新事务。 这可以是正确的行为。 例如，如果 TI 异常 1227 返回到客户端应用程序或记录在事件中，并且 HRESULT 为 8004D110，则表示无法接受具有此远程环境的新事务，因为在通信失败后未解析以前的事务。
当两阶段提交过程未完成时，CICS 必须将事务保持为 In-Doubt 状态，直到重新建立通信。 然后，TI 将执行恢复协议，以确保事务在所有节点上处于相同的状态。 必须正确配置 CICS 才能发生这种情况。
如果 CICS 意外终止，然后以冷状态重启，则任何尚未完成的事务的日志中都没有内存。 因此，这些事务无法自动恢复到一致状态。 验证所有事务在停止 CICS 之前是否已完成，或者使用相同的日志为热重启配置 CICS，以便可以恢复任何挂起的事务。
CICS 事务服务器允许管理员在事务 In-Doubt 属性中指定等待时间。 请确保指定一个值，该值足以在大多数情况下重新建立通信。 如果此超时在恢复处于 In-Doubt 状态的所有事务之前已过，则 CICS 将做出启发式决策，在本地解决这些问题。 如果此决策与 Microsoft DTC (分布式事务处理协调器) 为事务做出的决策冲突，则在手动重写以前事务的结果之前，无法启动新事务。
在 CICS 事务服务器之前的 CICS 版本中，恢复属性中没有等待时间。 将 Wait 值分配给 In-Doubt 属性不会导致 CICS 在尝试恢复时将事务置于 TI 请求的状态。 如果使用的是这些版本的 CICS，请将 In-Doubt 属性设置为 Backout 或 Commit。 如果生成的启发式决策不正确并阻止新事务开始，请使用 DTC 替代事务的结果。
在 Windows 事件日志中检查来自 SNA LU 6.2 Resync TP 服务的消息，指示事务未成功恢复。 按照建议的操作进行操作。 使用 Microsoft Transaction Server 的“事务列表”窗口显示挂起的事务。 右键单击事务以显示其属性。 解决此问题以同意 CICS 配置为启发式选择的状态，或者如果 CICS 意外终止并冷启动，则为已退出或中止状态。 日志中的 事件标识 CICS 选择的事务和状态。
注意
这不适用于 TCP/IP，因为 TCP/IP 不支持 ACID (原子、一致、隔离和持久的) 事务。