![[z/OS]](../images/ngzos.gif)
超时条件:分析诊断数据
以下准则提供在 SVC 转储中查找诊断数据的指示信息,这些数据可帮助您确定发生了何种超时情况。
应通过查找有 EC3 异常结束的任务开始:
- 通过输入以下命令,格式化超时的服务方的 TCB 总结:
ip summ format asid(x' address ')
其中 address 是服务方的地址空间标识。
查找有 EC3 完成代码的 TCB。忽略“主”线程上的任何 EC3 完成代码,该线程是总结格式中列出的第 4 个 TCB(3 个 MVS™ TCB 后的第 1 个)。WebSphere® 主线程是在 BBO_BOA::impl_is_ready 中等待的线程。在此线程上从未分派应用程序请求,因此没有要超时的。在超时处理期间,也会用 EC3 异常结束服务器区域的主线程,作为降低地址空间的机制。这就是为什么 EC3 完成代码可能出现在主线程中。这从不是超时的原因,而仅是超时处理的结果。
- 如果在 TCB 总结中没有 EC3 完成代码,请查看 systrace。
将 systrace 格式化为格林威治时间,因为要与之比较的其他时间戳记为格林威治时间。要采用格林威治时间格式,输入以下命令:
ip systrace all time(gmt)
可能您在 systrace 中也见不到 EC3 异常结束,因为 systrace 只能覆盖一小段时间。
- 您还可尝试查看 ip verbx mtrace 或 syslog,看 EC3 异常结束何时发生。您将需要该时间来确定请求的“结束”时间,它是达到超时值的格林威治时间。
可通过检查与 EC3 异常结束关联的原因码,确定哪些超时值有效。
原因码 | 说明 |
---|---|
04130002 | 控制器为此服务方区域发出一个 ABTERM,这是因为发生了事务超时。分派下的代码可能已进入紧密循环。 |
04130003 | 控制器为此服务方区域发出一个 ABTERM,因为它尝试将控制器请求传送到服务方区域时已挂起。目标请求已超时,但服务方当前正在复制请求。控制器通过发出 ABTERM,在采取操作前按常规时间间隔检查服务方的进展。 |
04130004 | 控制器为此服务方区域发出一个 ABTERM,因为发生了 WLM 队列超时。分派下的代码可能已进入紧密循环。 |
04130005 | 控制器为此服务方区域发出一个 ABTERM,这是因为发生了事务超时。事务已超时,但未找到与事务关联的当前请求。将终止与事务关联的服务方。 |
04130006 | 控制器线程在处理请求时遇到问题。请求已被排队到 WLM,并与服务方区域关联。需要终止关联的服务方区域以完成请求的清除。 |
04130007 | 控制器为此服务方区域发出一个 ABTERM,因为发生了 HTTP OUTPUT 超时。分派下的代码可能已进入紧密循环。 |
您可尝试查找方法名称以确定它是
httpRequest,
httpsRequest或
DispatchbyURI
还是某个其他方法。如果请求并不是明确地通过 HTTP 或 HTTPS 传输处理程序的请求,那么不考虑
protocol_http_output_timeout(HTTP) 和
protocol_https_timeout_output(HTTPS) 超时值。换而言之,如果请求是
DispatchbyURI方法,那么将通过 RMI/IIOP 协议接收该请求,因此
protocol_http变量无效。
然后可以使用带有 CEEDUMP 或 NTHREADS 选项的 IPCS verbexit LEDATA 获取该请求的堆栈跟踪。