某客户CICS WLM集群生产环境, 灾备演练前,cicswlmstat状态前后不一致

某客户CICS WLM集群生产环境,生产环境, 灾备演练前,查看WLM的运行状态如下:
[csp-cics2/#]cicswlmstat
BHG3963I 09/05/18 10:48:39 WLM status and routing status
HOST-NAME                WLM-NODE              STATUS  SELECTION     NORMAL      ABEND
Info-not-available       CSPSAR11      Region-Running          0          0          0
Info-not-available       CSPSAR21      Region-Running          0          0          0
Info-not-available       CSPSAR12      Region-Running          0          0          0
Info-not-available       CSPSAR13      Region-Running          0          0          0
Info-not-available       CSPSAR22      Region-Running          0          0          0
Info-not-available       CSPSAR23      Region-Running          0          0          0
Info-not-available       CSPSAR14      Region-Running          0          0          0
Info-not-available       CSPSAR15      Region-Running          0          0          0
Info-not-available       CSPSAR24      Region-Running          0          0          0
Info-not-available       CSPSAR25      Region-Running          0          0          0

灾备演练后,查看WLM的运行状态如下:

[csp-cics2/#]cicswlmstat
BHG3963I 09/09/18 04:59:13 WLM status and routing status
HOST-NAME                WLM-NODE              STATUS  SELECTION     NORMAL      ABEND
csp-cics1                CSPSAR11      Region-Running          0          0          0
csp-cics2                CSPSAR21      Region-Running          0          0          0
csp-cics2                CICSCSPS      Region-Running          0          0          0

就是wlm的运行状态,在灾备演练前后,不一致。 但现在生产环境的业务一切正常。
产生如此奇怪的问题,一时不得其解,最后求助IBM 同事和IBM实验室,IBM同事回复如下 :

阅读更多

Reason[2071]MQRC_STORAGE_NOT_AVAILABLE

客户给我发邮件,反映以下问题:也就是应用测试时,应用日志报错如下:

2018-09-27 08:53:40.688-0003 CSPS        aosRecvMerc.c 261 IBMMQ_ERROR  11825914
 CTISMQ00 k03201 8585228 31208821
连接MQ消息队列管理器[Css7806QMgr]失败
MQ Error:CompCode[2]MQRCMQCC_FAILED, Reason[2071]MQRC_STORAGE_NOT_AVAILABLE

经过分析,与搜索IBM 官网support网站,并且凭经验,综合分析,并给客户作出如下答复:

通过分析报错日志所得,针对以下问题,提出如下建议:
首先:
1、确认连接MQ的JAVA代码里,正确连接MQ 队列管理器。即队列管理器没有写错。
2、应用代码访问的MQ队列没有写错。也就是应用没有访问错误的MQ队列。
3、写入MQ 队列的报文不能太大,IBM官方建议写入队列的信息报文尽量不要超过4M,如果超过,请将报文分段写入MQ队列。
其次:
1、如果确认应用代码没有错误,并且读入MQ队列的报文没有超过4M,并且报文格式没有错误。那就按下面方法,调整系统文件大小限制和MQ 队列管理器的最大信息大小值:
如下所示:

*********************************************

  1. 1、In /etc/security/limits, increase the “data” ulimit for the account used to start the queue manager (usually root) to 192 MB or greater. Setting the data segment size (ulimit -d) to unlimited will resolve the issue. Note that the value is configured in 512 byte blocks, and -1 means unlimited.
  2. 2、In runmqsc, decrease the queue manager’s MAXMSGL attribute to something like 33554432, depending on the “data” ulimit value.

 

IHS升级到最新补丁报400/406错误

今年九月份,IBM 对外公布了IBM WebSphere Application Server远程代码执行漏洞,也就是CVE-2018-1567 漏洞,并在官网提供修补补丁以及匹配的补丁包。客户为了安全起见,也为了回应上面总部下发的修补要求,也就安排在省分公司,组织人员与安排时间,对现有的WAS系统修补这个漏洞。

客户的应用环境是IHS/WAS8.0.0.7,需要升级到was8.0.0.15,才可以打修补PI95973.  (今天才发现这个补丁已经升级,2018.10.13已经升级成PH03986),客户在上周四晚,在现有系统升级到IHS/WAS8.0.0.15,就打上这个IF95973, 打完后,客户业务同事就反映有个应用访问有点异常,具体问题 就是,发现有个应用没升级前,某个地级市 节点是正常往省行分享出来的端口POST数据,而升级后就不能正常 POST数据,并且在IHS的 access.log日志里,报400/406错误代码,奇怪的,有几个地级市往这个省行分享出来的接口POST数据,是正常,就这个地级市 POST数据时,报400/406错误。客户技术人员排查一天,都找不出问题 ,就要求我过去一起排查,过去后,要求客户重启布署在WAS的应用,并查看systemout.log,发现日志没有异常信息,确认WAS应用没有问题,再查看IHS/WAS的 versionInfo.sh输出信息,确认IHS/WAS版本已经成功升级到ihs/was8.0.0.15.  起初,怀疑是省行这边IHS作升级时,地级市的应用没有停止,致使地级市应用跟省行接口的网络进程不一致。致使地级市跟省行的IHS的网络进程 不同步。不一致。建议地级市重启地级应用程 序,但经过沟通,地级市应用不能重启,因为影晌面大。那只能将排查重点再放到省行IHS升级这个方向上,查看IHS的access.log时,除了发现这个地级市POST数据时报400/406错误,其它地级市节点访问省行这边的都正常。排查很久,都找不出问题所在,决定将IHS回滚,回复到没升级的IHS版本,即是ihs8.0.0.7版本。加上客户的业务运维技术人员也强烈要求回滚。于是进行IHS回滚,就从NBU备份,将IHS的版 本回复到ihs8.0.0.7.  回滚完后,重启IHS后,客户业务运维人员就反映,该地级市的应用的数据就正常POST到省行的接口上,原来问题 出在IHS的补丁升级上,

事后,查了查400/406错误,都是说跟MIME.type类型有关。估计是IHS8.0.0.7升级到IHS8.0.0.15后,新增了一些MIME.type 类型 ,而地级市的应用还是用回IHS8.0.0.7的MIME.type,这个应该是之前应用的开发人员沟通后,定义好所有的MIME.type类型的。IHS一升级后,就出现MIME.type类型不兼容的情况。而客户因为没有完整模拟到客户应用系统的数据环境,所以没有经过测试,就直接在生产环境升级IHS的版本到最新的IHS8.0.0.15版本,致使出现之前的应用无法访问的情况。需要最后回滚到没升级前的版本。