Home/ Questions/Q 8720291
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-13T07:00:26+00:00

I wrote a simple Java client using MQ v7 libraries (No JMS). I try

  • 0

I wrote a simple Java client using MQ v7 libraries (No JMS). I try to put a message in a queue using the following pattern:

Put a message
Wait for x minutes
Put a message again

It works but if the idle time is too long (between 5-7 minutes), I get the following error:

MQJE001: An MQException occurred: Completion Code 2, Reason 2195
MQJE007: IO error reading message data
Error occured during API call - reason code0
MQJE001: Completion Code 2, Reason 2009
MQJE001: An MQException occurred: Completion Code 2, Reason 2009
MQJE003: IO error transmitting message buffer
MQJE001: Completion Code 2, Reason 2009
MQJE001: An MQException occurred: Completion Code 2, Reason 2009
MQJE003: IO error transmitting message buffer
MQJE001: Completion Code 2, Reason 2009
MQJE001: An MQException occurred: Completion Code 2, Reason 2009
MQJE003: IO error transmitting message buffer
MQJE001: Completion Code 2, Reason 2009
MQJE001: An MQException occurred: Completion Code 2, Reason 2009
MQJE003: IO error transmitting message buffer
MQJE001: An MQException occurred: Completion Code 2, Reason 2009
MQJE003: IO error transmitting message buffer
MQJE001: Completion Code 2, Reason 2009
An MQSeries error occurred : Completion code 2 Reason code 2009
com.ibm.mq.MQException: MQJE001: Completion Code 2, Reason 2009
        at com.ibm.mq.MQQueue.put(MQQueue.java:1511)

After reading several threads on the subject, this error is usually creating FDC dumps but I have nothing in the system and queue manager logs. The channel is a SVRCONN channel.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    OK, there’s some interesting possibilities here and not enough description to narrow down very much so I’ll take the shotgun approach and you can go from there.

    Errors with that long a wait usually means the socket has timed out or been severed by a firewall or network policy.

    • Does the app specify Fail If Quiescing on the wait?
    • Which version of client and QMgr? In general, later versions of client are better, even with older QMgrs. The best case is recent client and recent QMgr in which case WMQ native protocol heartbeats are MUCH more reliable than TCP heartbeats. You mentioned V7 but that could be V7.0.0, V7.0.1, V7.1 or V7.5.

    In this case it is the client getting the 2195 so I’d expect errors to show on on the client side. The QMgr won’t cut an FDC file if the 2195 happens on the client side and after the socket is gone because at that point it can’t know about the error. The client-side diagnostics could shed more light on what’s going on.

    • Did you grab the jar files or install the client from IBM’s media? If you have the full client you have many options for tracing and local diagnostics. Otherwise you have only the Java tracing facility.
    • What do the local error log files or FDCs on the client side show?

    On the QMgr side, a 2009 usually results in a message saying the channel has disconnected, but no FDC. However, the QMgr may not know the channel has disconnected until TCP times out the socket and that interval by default on most systems is 2 hours. Therefore the error in the logs may not be written for up to two hours after the connection is lost.

    • The channels can be tuned to respond a LOT quicker than 2 hours. The exact tuning depends on the QMgr and client versions in use as discussed earlier.
    • When this happens, are there any orphaned channel instances left running? When you do a DIS CHS(svrconn name) are there any entries that are not accounted for by active programs? If you can’t tell, move the failing program to a dedicated SVRCONN channel.
    • What is the host server’s system-wide TCP timeout set to?

    As noted earlier, the versions you are using make a big difference in tuning and diagnostics. The very first thing I’d suggest if this is new development is to make sure you are using the V7.5 client. It will work with any QMgr but the tuning and diagnostics are better than earlier versions. You won’t get things like conversation sharing or read-ahead if the QMgr is at a version that doesn’t support them, but you do get the benefit of all the purely client-side improvements.

    • 0