IV66241: JMSWMQ1017 "NON-LOCAL MQ QUEUE NOT VALID" ERROR MESSAGE ISSUED WHEN IT IS USED AUTO-RECONNECT WITH TEMPORARY QUEUES

APAR status

• Closed as program error.

Error description

• An error is issued when it uses JMS and WMQ Ver.7.1.0. If it is
  used auto-reconnect facility, the following error is received
  when an application loses connection to a QM and it reconnects
  back to other different QM:
  
  JMSWMQ1017: non-local MQ queue 'MQ.QM.TEMP' not valid for
  receiving or browsing.] [JMSWMQ1017] [The MQ queue is not able
  to be opened, as it not local to the connected Queue Manager. ]
  [Connect to the Queue Manager for which this MQ Queue resides
  locally.] [{XMSC_DESTINATION_NAME=MQ.QM.TEMP}]
  
  The MQ.QM.TEMP model queue is correctly defined in both Queue
  Managers. The model queue is defined with QSGDISP(QMGR) in both
  Queue Managers.
  
  Error is because a JMS Connection object stores some information
  about the queue manager that they had originally connected to.
  
  This information is then used when an application creates a JMS
  Session from a JMS Connection, and then calls:
  
    Session.createTemporaryQueue()
  
  However, if automatic reconnection takes place, the queue
  manager name that had previously been stored is not updated.
  This means that, if an application calls:
  
    Session.createTemporaryQueue()
  
  after reconnection has occurred, the WebSphere MQ classes for
  JMS incorrectly opens the queue specifying the wrong queue
  manager name.
  
  Although this method call works, it leads to issues when the
  application then tries to use that temporary queue.
  

Local fix

• No Local Fix
  

Problem summary

• ****************************************************************
  USERS AFFECTED:
  This issue affects users of:
  
  - The WebSphere MQ V7.1 classes for JMS
  - The WebSphere MQ V7.5 classes for JMS
  - The WebSphere MQ V8 classes for JMS
  
  who have JMS applications that use JMS Connection Factory which
  has the following properties set:
  
  CLIENTRECONNECTOPTIONS : ANY
  CONNECTIONNAMELIST : a list of hostnames and ports>
  QMANAGER : ""
  
  and make use of automatic client reconnection.
  
  
  Platforms affected:
  MultiPlatform
  
  ****************************************************************
  PROBLEM DESCRIPTION:
  In order to create a temporary queue, an application calls the
  method Session.createTemporaryQueue(). While processing this
  method call, the JMS Session delegates the call to the JMS
  Connection that created it. The reason for this is that
  temporary queues are "owned" by a JMS Connection, even though
  they are created by JMS Sessions, as stated in section
  
  
  If an application creates a JMS Connection followed by a JMS
  Session, and calls QueueSession.createTemporaryQueue(), the
  WebSphere MQ classes for JMS build an MQOD Object Descriptor
  containing the following information:
  
  - The name of the queue manager that the JMS application is
  connected to (the ObjectQMgrName field)
  - The name of the model queue on the queue manager that the
  temporary queue will be based on (the ObjectName field)
  - The prefix that will be used to name the temporary queue (the
  DynamicQName field)
  
  An MQOPEN call is then made to open the temporary queue.
  
  Now, when a JMS Connection is created, it stores the name of the
  queue manager that it has connected to in a local variable.
  
  It was this "resolved queue manager name" that was then stored
  in the MQOD Object Descriptor passed to the queue manager as
  part of the MQOPEN.
  
  If automatic client reconnection had occurred between a JMS
  Connection being created and an application calling
  QueueSession.createTemporaryQueue(), then the "resolved queue
  manager name" stored in the JMS Connection would be incorrect.
  It would be set to the name of the queue manager that the
  application had originally connected to, rather than the queue
  manager the JMS Connection was currently connected to.
  
  For JMS applications that had reconnected to stand-alone queue
  managers, the call to QueueSession.createTemporaryQueue() would
  fail with a JMSException containing the following message:
  
  JMSWMQ2008: Failed to open MQ queue ''. JMS attempted to perform
  an MQOPEN, but WebSphere MQ reported an error. Use the linked
  exception to determine the cause of this error. Check that the
  specified queue and queue manager are defined correctly.
      : : : : : : : : : : : : : : : : : :
  Linked Exception com.ibm.mq.MQException: JMSCMQ0001: WebSphere
  MQ call failed with compcode '2' ('MQCC_FAILED') reason '2087'
  ('MQRC_UNKNOWN_REMOTE_Q_MGR').
  
  The reason for the JMSException was because the WebSphere MQ
  classes for JMS had issued an MQOPEN call to open the model
  queue on a different queue manager to the one that the
  application was connected to, and there was no path from the
  current queue manager to the original queue manager in the
  underlying WebSphere MQ infrastructure.
  
  
  If a JMS application had reconnected to a queue manager that was
  part of a WebSphere MQ network or a Queue Sharing Group, there
  was a path in the WebSphere MQ infrastructure from the current
  queue manager to the original queue manager and the specified
  model queue existed on the current queue manager, then the call
  to QueueSession.createTemporaryQueue() would work successfully.
  However, when the application then tried to create a
  QueueReceiver for that temporary queue, the call to
  QueueSession.createQueueReceiver(Queue) would try to reopen the
  queue to get messages from it - this would fail with a
  JMSException containing the message shown below:
  
  JMSWMQ1017: non-local MQ queue '' not valid for receiving or
  browsing. The MQ queue is not able to be opened, as it is not
  local to the connected Queue Manager. Connect to the Queue
  Manager for which this MQ Queue resides locally.
      : : : : : : : : : : : : : : : : : :
  Caused by: com.ibm.mq.MQException: JMSCMQ0001: WebSphere MQ call
  failed with compcode '2' ('MQCC_FAILED') reason '2045'
  ('MQRC_OPTION_NOT_VALID_FOR_TYPE').
  
  The WebSphere MQ classes for JMS had actually opened a local
  definition (on the queue manager that it was currently connected
  to) of a remote model queue (hosted on the original queue
  manager). It is not possible to open a remote queue to get
  messages from it, and so a JMSException containing WebSphere MQ
  Reason Code 2045 was generated.
  

Problem conclusion

• The WebSphere MQ classes for JMS have been updated to ensure
  that, whenever an application calls the method
  Session.createTemporaryQueue(), the ObjectQMgrName field in the
  MQOD Object Descriptor is left blank. This ensures that the
  temporary queue is created on the queue manager that the
  application is currently connected to.
  
  ---------------------------------------------------------------
  The fix is targeted for delivery in the following PTFs:
  
  Version    Maintenance Level
  v7.1       7.1.0.7
  v7.5       7.5.0.6
  v8.0       8.0.0.3
  
  The latest available maintenance can be obtained from
  'WebSphere MQ Recommended Fixes'
  http://www-1.ibm.com/support/docview.wss?rs=171&uid=swg27006037
  
  If the maintenance level is not yet available information on
  its planned availability can be found in 'WebSphere MQ
  Planned Maintenance Release Dates'
  http://www-1.ibm.com/support/docview.wss?rs=171&uid=swg27006309
  ---------------------------------------------------------------
  

Temporary fix

Comments

APAR Information

• APAR is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

Fix information

• Fixed component name

  WMQ LIN X86 V7

• Fixed component ID

  5724H7224

Applicable component levels

• R710 PSY

     UP