Showing posts with label MQ Error. Show all posts
Showing posts with label MQ Error. Show all posts

Tuesday 25 April 2017

Websphere mq queue manager quiescing or exitvalue 49 ibm mq

Websphere mq queue manager quiescing or exitvalue 49 ibm mq


Error : If Queue Manager not stopped correctly than we would not be able to start Queue manager. Queue manager exists with "exitvalue=49". 

In the log from the MQ manager the last messages is this : 
------------------------------------------------------------------------------- 
15-11-2007 16:06:06 - Process(3796.2 User(BATWBIADM) Program(amqrmppa.exe) 
AMQ9542: Queue manager is ending. 

EXPLANATION: 
The program will end because the queue manager is quiescing. 
ACTION: 
None. 
----- amqrmssa.c : 2385 ------------------------------------------------------- 
But when I try to start the manager I get : 
WebSphere MQ queue manager 'MQSINT02' ending. 
exitvalue = 49 

Solution: When Queue manager tried to stop that time some process was running related to Queue Manager so not stopped correctly.

Run below command using dspmq and check status of Queue Manager.

websphere mq queue manager quiescing or exitvalue 49 ibm mq

Now kill all the process related to these Queue managers or Restart system machine and start IBM MQ Series. 

MQRC 2063 (MQRC_SECURITY_ERROR) in rfhUtilc

MQRC 2063 (MQRC_SECURITY_ERROR) in rfhUtilc


MQ security error 2063: I was able to connect with remote system's Queue manager
through rfhUtilc.But, suddenly now I am getting 2063 MQ error when I am trying 
to connect using rfhUtilc. I observed, password was changed for user through we 
log on in IBM Websphere MQ(Installation1) and IBM MQSeries.

Solution: Stop IBM MQSeries and IBM Websphere MQ(Installation1) and
change password for user.


Now restart IBM MQSeries and check if all Queue Manager is started or not.

Related Topic:


Wednesday 22 February 2017

MQ Error: 2035 MQRC_NOT_AUTHORIZED or AMQ4036 or JMSWMQ2013

MQ Error: 2035 MQRC_NOT_AUTHORIZED or AMQ4036 or JMSWMQ2013


Problem: If we create a new queue manager in WebSphere MQ 7.1, 7.5, 8.0 or 9.0 or later and try to use a user id(commonly mqm for UNIX and MUSR_MQADMIN on Windows) that is an MQ Administrator to access the queue manager via a server-connection channel (remotely from another host, or locally from the same host and not using bindings mode). You get an error with reason code 2035:

2035 MQRC_NOT_AUTHORIZED

Related error codes:
MQ Explorer => AMQ4036 
MQ classes for JMS => JMSWMQ2013


org.springframework.jms.JmsSecurityException: JMSWMQ2013: The security authentication was not valid that was supplied for QueueManager '' with connection mode 'Client' and host name 'localhost(1417)'.; nested exception is com.ibm.msg.client.jms.DetailedJMSSecurityException: JMSWMQ2013: The security authentication was not valid that was supplied for QueueManager '' with connection mode 'Client' and host name 'localhost(1417)'.
Please check if the supplied username and password are correct on the QueueManager to which you are connecting.; nested exception is com.ibm.mq.MQException: JMSCMQ0001: WebSphere MQ call failed with compcode '2' ('MQCC_FAILED') reason '2035' ('MQRC_NOT_AUTHORIZED'). 

Note: The MQ Administrator can remotely access (via a server-connection channel) without problems other MQ queue managers at version 6 or 7.0.x.

Solution :  If we want the MQ Administrator to be able to access the queue manager via client channels, we have different approach to achieve:

1a. We can add the following two Channel Authentication Records:

The first rule blocks administrative users and the MCAUSER "nobody" (which prevents someone from creating a user ID "nobody" and putting it into an authorized group).
$ runmqsc QmgrName
SET CHLAUTH(*) TYPE(BLOCKUSER) USERLIST('nobody','*MQADMIN')


The second rule provides a reduced blacklist for SYSTEM.ADMIN channels that allows administrators to use these. It is assumed here that some other CHLAUTH rule such as an SSLPEERMAP has validated the administrator’s connection or that an exit has done so.


SET CHLAUTH(SYSTEM.ADMIN.*) TYPE(BLOCKUSER) USERLIST('nobody')

The above rules apply to SYSTEM.ADMIN.SVRCONN which is used by the MQ Explorer. 

If you are using another user-defined channel, such as MY.ADMIN.SVRCONN, then you need to add the following two records:
SET CHLAUTH(MY.ADMIN.SVRCONN) TYPE(ADDRESSMAP) ADDRESS(*) USERSRC(CHANNEL)
SET CHLAUTH(MY.ADMIN.SVRCONN) TYPE(BLOCKUSER) USERLIST('nobody')


Note: it is not advisable to use SYSTEM.DEF.* channels for active connections. The system default channels are the objects from which all user-defined channels inherit properties. The recommended practice is that SYSTEM.DEF.* and SYSTEM.AUTO.* channels should NOT be configured to be usable.

1b. This is a variation of (1a) but allowing the MQ Administrator to only use a particular host.

The first rule blocks MCAUSER "nobody".
SET CHLAUTH(SYSTEM.ADMIN.SVRCONN) TYPE(BLOCKUSER) USERLIST('nobody')

The second rule removes all access to SYSTEM.ADMIN.SVRCONN ...
SET CHLAUTH(SYSTEM.ADMIN.SVRCONN) TYPE(ADDRESSMAP) ADDRESS(*) ACTION(REMOVE)

And the third rule adds an entry for the server that needs access.
SET CHLAUTH(SYSTEM.ADMIN.SVRCONN) TYPE(ADDRESSMAP) ADDRESS(9.xx.xx.8y) USERSRC(CHANNEL)


1c. Disable the Channel Authentication Records feature:


$ runmqsc QmgrName
DISPLAY QMGR CHLAUTH
AMQ8408: Display Queue Manager details.
QMNAME(TEST01) CHLAUTH(ENABLED)

ALTER QMGR CHLAUTH(DISABLED)


WARNING: Disabling this new feature is not recommended for MQ 7.1 production queue managers due to security implications.
Note that disabling CHLAUTH results in a policy that accepts administrative connections by default. The administrative effort to lock down administrative access with CHLAUTH(DISABLED) is much greater than to do so with CHLAUTH(ENABLED). It is therefore recommended to leave CHLAUTH(ENABLED) and use the other security features of WebSphere MQ V7.1 to authenticate administrator connections.

Thursday 2 February 2017

com.ibm.msg.client.jms.DetailedIllegalStateException: JMSWMQ2007

com.ibm.msg.client.jms.DetailedIllegalStateException: JMSWMQ2007

Problem: I was trying to set expiration time for my MQ messages using Spring JMS Template.
        jmsTemplate.setExplicitQosEnabled(true);
        jmsTemplate.setTimeToLive(expiryTime); 
And for expiration report, trying to set Textmessage properties.
       textMessage.setIntProperty(JmsConstants.JMS_IBM_REPORT_EXPIRATION,  MQC.MQRO_EXPIRATION_WITH_DATA);
        textMessage.setIntProperty(JmsConstants.JMS_IBM_REPORT_PASS_MSG_ID, MQC.MQRO_PASS_MSG_ID); 
When I am trying to execute program, getting below MQ exception.

com.ibm.msg.client.jms.DetailedIllegalStateException: JMSWMQ2007,Failed to send a message to destination . JMS attempted to perform an MQPUT or MQPUT1; however WebSphere MQ reported an error. Use the linked exception to determine the cause of this error.

com.ibm.msg.client.jms.DetailedIllegalStateException: JMSWMQ2007

  

 

 

Solution:  When we set property for expiration report, need to also set ReplyToQueue and ReplyToQueueManager. If any message got expired than Expiration report will be sent back to mentioned ReplyToQueueManager and ReplyToQueue by MQ Queue Manager.

private void setJMSProperty(TextMessage textMessage, String ReplyToQueueMgr, String ReplyToQueue) throws JMSException {
        MQQueue replyToQ = new MQQueue(ReplyToQueueMgr, ReplyToQueue);
        Destination replyTo = (Destination) replyToQ;
        textMessage.setJMSReplyTo(replyTo);
        textMessage.setIntProperty(JmsConstants.JMS_IBM_REPORT_EXPIRATION, MQC.MQRO_EXPIRATION_WITH_DATA);
        textMessage.setIntProperty(JmsConstants.JMS_IBM_REPORT_PASS_MSG_ID, MQC.MQRO_PASS_MSG_ID);
    }

 

How to set MQ instance for installation   

If your machine installed with number of MQ instance, than by using below command we can set instance.

  • Go to bin folder of MQ installation path in command prompt, in my system it is 

    C:\Program Files (x86)\IBM\WebSphere MQ\bin

    Execute the command "setmqinst -n Installation(n) -i" where n is 1,2,3.... I wanted to set in my machine as installation1 so command will be.

     C:\Program Files (x86)\IBM\WebSphere MQ\bin\setmqinst -n Installation1 -i


Important summary:  

1. How to set IBM MQ expiration time

jmsTemplate.setExplicitQosEnabled(true);
jmsTemplate.setTimeToLive(expiryTime);

2. How to set IBM MQ expiration report

  textMessage.setIntProperty(JmsConstants.JMS_IBM_REPORT_EXPIRATION,  MQC.MQRO_EXPIRATION_WITH_DATA);
        textMessage.setIntProperty(JmsConstants.JMS_IBM_REPORT_PASS_MSG_ID, MQC.MQRO_PASS_MSG_ID); 

3. How to set IBM MQ ReplyToQueue and ReplyToQueueManager

private void setJMSProperty(TextMessage textMessage, String ReplyToQueueMgr, String ReplyToQueue) throws JMSException {
        MQQueue replyToQ = new MQQueue(ReplyToQueueMgr, ReplyToQueue);
        Destination replyTo = (Destination) replyToQ;
        textMessage.setJMSReplyTo(replyTo);
        textMessage.setIntProperty(JmsConstants.JMS_IBM_REPORT_EXPIRATION, MQC.MQRO_EXPIRATION_WITH_DATA);
        textMessage.setIntProperty(JmsConstants.JMS_IBM_REPORT_PASS_MSG_ID, MQC.MQRO_PASS_MSG_ID);
    }

IBM MQ reason code 2087 (AMQ4048)

IBM MQ reason code 2087 (AMQ4048)

ProblemMy window machine "A" installed with IBM WebSphere MQ 7.5 version and other system "B" also installed with IBM WebSphere MQ 7.5 version.
  • I created Queue manager with name of "MQ1" on machine "A" and with the same Queue manager name "MQ1" created on other machine "B". 
  • Created Remote Queue and related transmission queue and sender channel on machine "A" under Queue manager "MQ1". 
  • Created Local Queue and receiver channel on machine "B" under Queue manager "MQ1". 
  • Started sender channel and receiver channel, both are in running state. 
  • Tried to put message on remote queue and got below error.
IBM MQ reason code 2087 (AMQ4048)



Solution: I searched reason code on IBM site "https://www.ibm.com/support/knowledgecenter/SSFKSJ_9.0.0/com.ibm.mq.tro.doc/q041500_.htm" and found reason as Queue manager name must be different. After changing Queue manager name, able to put and get messages.
Note: Remote queue name and local queue name was same but this doesn't create any problem.

 

Saturday 21 January 2017

Solution for sender channel status retrying

Solution for sender channel status retrying


Scenario 1: My window machine installed with IBM WebSphere MQ 7.5 version and z/OS machine installed with IBM WebSphere MQ 7.0. I have one remote queue on my window 

machine which sends messages to z/OS machines local Queue. I am able to send messages from my remote queue to z/OS local queue using sender channel, Receiver Channel and Transmission Queue. Some network interruption happened on my window machine and lost connection with Z/OS machine. At the time of network interruption, my sender channel and Z/OS receiver channel was running. when connection restored with these two machine my sender channel status becomes "Retrying" and receiver channel status still showing running. When I looked on error log AMQERR01.LOG for sender channel, this look like below. 
Solutionfor sender channel status retrying_amqerror1
I tried with lots of option like stop and start Sender Queue Manager, Sender channel, checked MAX instance defined on both machine but nothing worked. I also applied fix pack of 7.5.0.5 on MQ7.5 by reading below article. IT02422: WMQ V7.5 JAVA APPLICATION FAILS WITH REASON CODE 2025 (MQRC_MAX_CONNS_LIMIT_REACHED) AFTER NETWORK OUTAGES(http://www-01.ibm.com/support/docview.wss?doc=aimwmq&rs=171&uid=swg21110505) but this also not worked.

Solution: Finally I got one solution. forcefully stopped sender channel and receiver channel(STOP CHL(rcvr chl name) MODE(FORCE)), both channel status should be STOPPED now. start receiver channel.Stop and start Queue manager of sender channel. Than, finally start sender channel. In my case this worked :)

Scenario 2: I configured my remote Queue and local Queue on window machine. Through java application, I am trying to put messages on remote Queue and try to get those messages on my local queue, but my messages got stuck on transmission Queue and sender channel goes into Retrying state.
Note: Earlier my sender channel connected with other system's IP and able to send and receive messages, when I changed IP with my local system than messages got stuck in transmission queue and sender channel goes into Retrying state.

Solution: I found one temporary solution. Deleted old transmission Queue and created new one and given reference to sender channel and Remote queue.

In above 2 scenario, difference in 1st scenario is, sender channel goes in retrying state when one system lost connection with other system where as in 2nd scenario, changed IP address in sender channel.


Related Topic:

Spring jms code for ibm mq example