Pages

Saturday, July 27, 2013

BMXAA6464I and BMXAA6473E Error Msgs

After restarting one of my fail over nodes I notice no Maximo when I tried to log in and the following in msg in the log file.

[INFO] BMXAA6464I - A registry was not found. The system is creating a registry.
BMXAA6473E - Maximo failed to start.

Quick check of the RMI server showed they were down so I checked the MonitoringPolicy on the RMI server and it was set to STOPPED not PREVIOUS. I started the RMI server update the MonitoringPolicy  to PREVIOUS and restarted the node to test the change. The system started as expected.

Saturday, July 13, 2013

My BMXAA1347E was really a CWSIK0024E ??? You don't say

I have been working the last few months on a Maximo disaster recovery config for our servers and during QA testing I ran into a strange issue with one of our MIF integrations. Every time I tried to send over a transaction I got a "BMXAA1347E - A message could not be sent to the Java Message Service (JMS) destination".

Overview
The integration in question is a sequential inbound (or Enterprise Service ) that uses a interface table as the entry point. Records are inserted into the interface table were a database trigger inserts a record into the MXIN_INTER_TRANS table. The JMSQSEQCONSUMER SEQQIN cron task then picks the records up and processes it using a WebSphere SIB running in it's own Maximo cluster.

The Error

After I inserted a record into the interface table I quickly queried the MXIN_INTER_TRANS table and returned was one row confirming that the trigger worked as expected. After the cron task ran I noticed the one row was updated with an error msg. I quickly checked the standard out and found the following.


7/10/13 23:00:19:512 MDT] 00000050 SystemOut     O 10 Jul 2013 23:00:19:512 [ERROR] BMXAA1347E - A message could not be sent to the Java Message Service (JMS) destination jms/maximo/int/queues/sqin.psdi.util.MXApplicationException: BMXAA1347E - A message could not be sent to the Java Message Service (JMS) destination jms/maximo/int/queues/sqin. at psdi.iface.jms.JMSProducer.handleError(JMSProducer.java:275) at psdi.iface.jms.JMSProducer.sendMessage(JMSProducer.java:216) at psdi.iface.jms.MEAQueueProcessor.writeToQueue(MEAQueueProcessor.java:263) at psdi.iface.jms.MEAQueueProcessor.writeDataToQueueIn(MEAQueueProcessor.java:225) at psdi.iface.intertables.IfaceTbCronTask.sendMessage(IfaceTbCronTask.java:929) at psdi.iface.intertables.IfaceTbCronTask.processData(IfaceTbCronTask.java:1008) at psdi.iface.intertables.IfaceTbCronTask.processIfaceData(IfaceTbCronTask.java:835) at psdi.iface.intertables.IfaceTbCronTask.cronAction(IfaceTbCronTask.java:519) at psdi.server.CronTaskManager.callCronMethod(CronTaskManager.java:1556) at psdi.server.CronTaskManager.access$400(CronTaskManager.java:84) at psdi.server.CronTaskManager$CronThread.run(CronTaskManager.java:2074)

Trouble Shooting 
I began comparing the JMS config from our PTCH and DEV environments to QA because the same test had passed in each of the weeks prior.

After many hours nothing... I noticed that the MIF global dir was filling up with XML records from the cron task retrying the interrogation so I deleted all but the most recent xml files.

I then decided to try and upload a XML record that the cron task had already created (study item from
Test 000-501: IBM Maximo Asset Management V7.5 Infrastructure Implementation). From the start center I went to Integration -> External Systems -> <The System in Question and > and the Enterprise Services tab. From here I selected the service in question and clicked the Data Import button. I then browsed to the MIF global dir and selected the last record processed. It did not work but I got much more detail from the log of the server I was logged onto.


[7/11/13 9:02:42:417 MDT] 00000081 SystemOut     O DEBUG: Control uploadfile could not be found in order to process event loadData :: 
[7/11/13 9:02:42:516 MDT] 00000081 SystemOut     O 11 Jul 2013 09:02:42:516 [INFO] wrote data to Queue jms/maximo/int/queues/sqin
[7/11/13 9:02:42:803 MDT] 00000081 ServiceLogger I com.ibm.ws.ffdc.IncidentStreamImpl initialize FFDC0009I: FFDC opened incident stream file C:\IBM\WebSphere\AppServer\profiles\Custom01\logs\ffdc\maxqa_ui08_00000081_13.07.11_09.02.42_0.txt
[7/11/13 9:02:42:815 MDT] 00000081 ServiceLogger I com.ibm.ws.ffdc.IncidentStreamImpl resetIncidentStream FFDC0010I: FFDC closed incident stream file C:\IBM\WebSphere\AppServer\profiles\Custom01\logs\ffdc\maxqa_ui08_00000081_13.07.11_09.02.42_0.txt
[7/11/13 9:02:42:829 MDT] 00000081 SystemOut     O 11 Jul 2013 09:02:42:821 [ERROR]
CWSIA0053E: An exception was received during the call to the method JmsSessionImpl.commitTransaction (#3): com.ibm.wsspi.sib.core.exception.SIRollbackException: 

CWSIC2008E: This transaction cannot commit as an operation that was performed within the transaction boundary failed. The first operation that failed generated the following exception: com.ibm.ws.sib.processor.exceptions.SIMPSendAllowedException: CWSIK0024E: The destination sqinbd is send disallowed for messaging engine maximo_if.000-ifjmsbus...

All right ! 

A quick look up of  CWSIK0024E took me here  where I learned that

CWSIK0024E: The destination {0} is send disallowed for messaging engine {1}.
Explanation An attempt has been made to send a message to a destination and a check has been made to ensure that a queue point is available for this destination. This check failed as the only queue point for this destination is send disallowed.
Action Update the queue point for the destination so it is send allowed and retry the send operation.

Solution 
I found that under  Buses > ifjmsbus > Destinations > sqinbd > Queue points > sqinbd@maximo_if.000-ifjmsbus the "Send allowed" check box was not checked in QA and every other environment has this checked. The XML file that stores this info is cells / Cell01 / clusters / maximo_if / sib-engines.xml

WebSphere docs say this about "Send allowed"

Send allowed

Clear this option (setting it to false) to stop messages from being put onto this message point.
Required No
Data type Check box

Conclusion 

Check the "Send Allowed" on queue points because without this checked messages will not be processed.