0

I am processing some data in a java program and putting data to the queue using a put operation. I have a connection created to the MQ using the following parameters - QueueManagerName,HostName,TCP/IP Port,ServerConnectionChannel,CCSID ,queueName and Encoding.

Issue is that i get the following error message when i try to put data to MQ .

Strange thing about this is that the error is thrown only for the first put attempt in a period of time,All subsequent attempts are successful. Do you know why this might be? I see a related post here.I have no access to MQ Admin stuff.I wanted to highlight the intermittency in this issue to see if we can pinpoint a root cause for this scenario?

[ADA.600.1055] Exception caught Get : Unable to put message to queue <<QueueName>> on <<QueManagerName>>; condition code is "2", reason code is "2195".Completion Code 2, Reason 2195 Unable to put message to queue <<QueueName>> on <<QueManagerName>>; condition code is "2", reason code is "2195". (Linked Exception:Completion Code 2, Reason 2195)

Here is the MQ Java Trace for this issue

**11:20:41** [1590765641717] Thread: HTTP Handler <<IP Address>>, Object: com.ibm.mq.MQInternalCommunications@6574210e <== send() exit
**11:20:41** [1590765641717] Thread: HTTP Handler <<IP Address>>, Object: com.ibm.mq.MQInternalCommunications@6574210e ==> receive() entry
**11:20:41** [1590765641717] Thread: HTTP Handler <<IP Address>>, Object: com.ibm.mq.MQInternalCommunications@6574210e <== receive (via exception)() exit
**11:20:41** [1590765641717] Thread: HTTP Handler <<IP Address>>, Object: com.ibm.mqservices.MQInternalException ==> MQInternalException constructor() entry
**11:20:41** [1590765641717] Thread: HTTP Handler <<IP Address>>, Object: com.ibm.mqservices.MQInternalException <== MQException private constructor() exit
**11:20:41** [1590765641717] Thread: HTTP Handler <<IP Address>> <== MQSESSIONClient::MQPUT() exit
**11:20:41** [1590765641717] Thread: HTTP Handler <<IP Address>>, Object: com.ibm.mq.MQException: Completion Code 2, Reason 2195 ==> MQException constructor: CC = 2 RC = 2195 thrown by com.ibm.mq.MQQueue@5d644fb4() entry
**11:20:41** [1590765641717] Thread: HTTP Handler <<IP Address>>, Object: com.ibm.mq.MQException: Completion Code 2, Reason 2195 <== MQException constructor() exit
**11:20:41** [1590765641717] Thread: HTTP Handler <<IP Address>>, Object: com.ibm.mq.MQQueueManager@991a6f4 ==> errorOccurred() entry
**11:20:41** [1590765641718] Thread: HTTP Handler <<IP Address>> ==> ReasonCodeInfo::getReasonCodeCategory() entry
**11:20:41** [1590765641718] Thread: HTTP Handler <<IP Address>> <== ReasonCodeInfo::getReasonCodeCategory() exit

Here is the QueueManager Error for this issue

12:55:43 - Process(16266.47933) User(mqm) Program(amqrmppa) AMQ9259: Connection timed out from host '<<IP_ADDRESS>>'. EXPLANATION: A connection from host '<<IP_ADDRESS>>' over TCP/IP timed out. ACTION: Check to see why data was not received in the expected time. Correct the problem. Reconnect the channel, or wait for a retrying channel to reconnect itself.

JoshMc
  • 10,239
  • 2
  • 19
  • 38
Divya MV
  • 2,021
  • 3
  • 31
  • 55
  • 1
    It may be helpful if you could post your code and version of MQ you are using – Shashi May 27 '20 at 09:37
  • @Shashi I dont have much of a code ..I am using a tool built in Java called WebMethods to put data to Queue... – Divya MV May 27 '20 at 13:40
  • Check the queue manager errors folder and the system errors folder for FDCs. MQRC_UNEXPECTED_ERROR (2195) should never happen and means that something untoward took place. Usually time to open a PMR. If you have no access to the machine where the queue manager is, you need to talk to someone who does. It is unlikely you can diagnose this from the outside. – Morag Hughson May 28 '20 at 04:44
  • @JoshMc I think i can get hold of the trace.....Let me come back with it...thank you – Divya MV May 28 '20 at 13:00
  • @JoshMc - I don't see how an MQ Java trace would help if it's a queue manager side abend? Of course, if it's a problem in the MQ Java layer then it would. – Morag Hughson May 28 '20 at 23:45
  • @JoshMc - how do you know it is Java side? If the queue manager abends, you will receive a 2195 reason code - I don't see how you can tell the difference from queue manager side abend and client side abend just from a reason code? Perhaps I'm missing something? – Morag Hughson May 29 '20 at 00:41
  • @JoshMc Perhaps 2195s are more common, in your experience, in the Java layer? I rarely use Java, so when I see a 2195 it is usually from the queue manager, and I head for the FDC to find out what happened. – Morag Hughson May 29 '20 at 05:05
  • @JoshMc I have updated the question with Java trace for the issue. Can you please check? – Divya MV May 29 '20 at 15:35
  • 1
    I don't see the MQ version of the jarswas ever provided, can you provide that? What you method was used to start the trace, it looks less verbose than I expected, also in recent versions the trace abbreviates `com.ibm.mq.` to `c.i.m.` to shorten the line. If this is a old out of support version of MQ I would suggest that you first try with something supported. 8.0 and below are all out of support. 9.0 goes out of support September 30 2021. So 9.1 would be the best choice. There is a "Java-All" client you can download that just comes as a self extracting jar of just the required jars. – JoshMc May 29 '20 at 17:39
  • @JoshMc The MQ version being used is 6.0.2...upgrade is not within my hands. I got some error Log from the MQ Admin team for my server's IP Address – Divya MV Jun 02 '20 at 06:39
  • @JoshMc 06/01/20 ```12:55:43 - Process(16266.47933) User(mqm) Program(amqrmppa) AMQ9259: Connection timed out from host '<>'. EXPLANATION: A connection from host '<>' over TCP/IP timed out. ACTION: Check to see why data was not received in the expected time. Correct the problem. Reconnect the channel, or wait for a retrying channel to reconnect itself.``` – Divya MV Jun 02 '20 at 06:40
  • I don't have a time out set for my connection..Why else can this happen? – Divya MV Jun 02 '20 at 06:41
  • @JoshMc No..there isn't a Firewall between My server and the queue Manager – Divya MV Jun 02 '20 at 07:35
  • What is the HBINT set to on the SVRCONN channel you connect to? Clients older than v7.0 do not perform bidirectional Heart Beats, wonder if your connection is timing out, ex, if you have not put for a long time there is really no traffic on the connection. I would check the tcp keepalive setting for the OS on the client and queue manager (this is OS level not MQ level, TCP will negotiate to the lowest value). – JoshMc Jun 03 '20 at 11:32
  • If your period of time before the "first put" is longer than this value and the QM has `TCP: Keepalive=yes` set in the qm.ini which is fairly standard, then the QM could be timing out for this reason. I suspect if you review the time of the QM's AMQ9259 timeout message, it is some time prior to your failed PUT, you probably then reconnect and the 2nd PUT is successful. You could also infer the tcp keepalive by calculating the time between the last successful PUT and the AMQ9259 error. – JoshMc Jun 03 '20 at 11:36
  • @JoshMc Let check this with the MQ Admins and get back.. – Divya MV Jun 05 '20 at 05:11
  • @JoshMc HBINT is 300 Secs. KeepAlive of OS on the client should not be a problem as the client is pushing data to other queues just fine. – Divya MV Jun 05 '20 at 13:37
  • @JoshMc Can you please direct me on how to find the KeepAlive for O/S? – Divya MV Jun 05 '20 at 15:21
  • I mentioned above, the queue managers qm.ini would need a TCP stanza with KeepAlive=yes for it to be enabled for the queue manager. To check what the keepalive setting is that will be used if enabled is a OS level setting and checking would be OS dependent, it is negotiated to the lower of the two ends of the TCP connection, if turned on at qm.ini level you would need to check client and qmgr to know what it is. If you do not enable it on client side it just means that you will not end a connection, but if enabled on the QM side it will still get ended by the QM if no traffic for that time. – JoshMc Jun 05 '20 at 20:05
  • MQ Admin told me that there was a clientIdle configuration set on the QM which he removed and the problem did not reoccur. – Divya MV Jun 25 '20 at 05:12

0 Answers0