Skip to main content

2033 MQRC NO MSG AVAILABLE - Middleware News

2033 MQRC NO MSG AVAILABLE - Middleware News


Problem(Abstract)

You attempt to get a message from your queue. The getting application fails with the following: 2033 0x000007f1 MQRC_NO_MSG_AVAILABLE
Cause

The following are the most likely causes for MQRC 2033:

* There are no messages on the queue.
* The unit of work (UOW) for the MQPUT was not committed.
* The messages have expired.

Resolving the problem

* Consider this reason code as a normal condition and handle this condition in your getting application. Use the MQGET MQGMO_WAIT option and retry the MQGET.
o The amqsget sample programs demonstrate the use of MQGET MQGMO_WAIT.

* Verify that the putting application is committing the UOW. The current depth of the queue increments at MQPUT. However, messages are not available to the getting application until they are committed.

* Messages that have expired will be counted in the current depth of the queue and they are discarded at the point of MQGET. Expired messages are never returned to the getting application. You may want to increase your message expiry time or use unlimited expiry for your messages.


Note: There are more reasons for MQRC 2033. This documents the most common causes.





MQGET fails with MQRC 2033



Problem(Abstract)

Your WebSphere MQ for z/OS batch job puts messages to a queue. Your trigger-started program attempts to get the messages from the queue and fails with reason code

2033 0x000007f1 MQRC_NO_MSG_AVAILABLE

Cause

The batch job has not committed the unit of work.

Resolving the problem
Your batch job will determine when the unit of work is complete. Use the MQCMIT call to make messages available to getting applications, or use MQPMO_NO_SYNCPOINT (the default option on z/OS is MQPMO_SYNCPOINT).
Do not always consider MQRC_NO_MSG_AVAILABLE to be a failure. Your getting application should be designed to handle MQRC 2033, because it is a very common reason code.



A GET WAIT CAN RESULT IN MQRC=2033, ALTHOUGH MESSAGES ARE ON QUEUE.


Error description

* Application has few GET-Wait instances on a queue and messages
will be GETed by GroupID. Depending on number of messages and
the number of parallel instances, application will get 2033 RC,
although messages still existing on queue. The second/reGET is
always successful. If only one instance of the application is
used, the problem does not exist.

The following describes the scenario:
Application 1 puts 3 messages in group
C3E2D840D8C1F0F1161D6BD8551672C8C309DC2393D329CE to the request
queue, the last message having the last_msg_in_group flag
turned on (i.e the group is complete).

Application 1 then does a get on the reply, specifying this
groupid and MQGMO_ALL_MSGS_AVAILABLE. At this point there are
no messages matching the groupid on the reply queue, and so
CSQIMGC1 returns CSQI_GROUP_INCOMPLETE. This is translated to
MQRC_NO_MSG_AVAILABLE, but beause the wait interval has not
expired, this is not returned to the caller, and Application
1 is put on the getwait chain for the reply queue.

Application 2 then follows the same sequence, but for group
C3E2D840D8C1F0F115D1DCF8551672C8C309DC239539F90C. At this
point the getwaiter chain contains
Application 1->Application 2.

Application 3 then gets the 3 messages put by Application 2,
and puts them on the reply queue. Each time one of these
messages is put CSQM1PGW is called to locate a suitable waiter
interval (1s) expires, and MQRC_NO_MSG_AVAILABLE is returned
to the caller, despite the messages existing on the queue. If
the get is redriven it will find the messages and succeed.

Local fix


Problem summary

*****************************************************************
* USERS AFFECTED: All users of WebSphere MQ for z/OS V7 *
****************************************************************
* PROBLEM DESCRIPTION: When using MQGMO_ALL_MSGS_AVAILABLE and *
* message grouping, MQRC 2033 *
* (MQRC_NO_MSG_AVAILABLE) is returned *
* even though the queue contains suitable *
* messages. *
****************************************************************
* RECOMMENDATION: *
****************************************************************
The problem is in the handling of getwaits when
MQGMO_ALL_MSGS_AVAILABLE and MQMO_MATCH_GROUP_ID is used.
Specifically a group of messages (by GROUPID) arrives and causes
the wrong getwaiter to be alerted. The correct getwaiter is
never notified and eventually its getwait time expires and MQRC
2033 is returned. The wrong getwaiter does not remove the
messages from the queue as they are for the wrong group and they
remain on the queue.

Problem conclusion

* CSQMGSGW has been changed to check for correct GROUPID when
alerting a getwaiter who has specified MQGMO_ALL_MSGS_AVAILABLE
and MQMO_MATCH_GROUPID
000Y
CSQMGSGW

Comments

adsrerrapop

Popular posts from this blog

IBM Websphere MQ interview Questions Part 5

MQ Series: - It is an IBM web sphere product which is evolved in 1990’s. MQ series does transportation from one point to other. It is an EAI tool (Middle ware) VERSIONS:-5.0, 5.1, 5.3, 6.0, 7.0(new version). The currently using version is 6.2 Note: – MQ series supports more than 35+ operating systems. It is platform Independent. For every OS we have different MQ series software’s. But the functionality of MQ series Default path for installing MQ series is:- C: programfiles\BM\clipse\SDK30 C: programfiles\IBM\WebsphereMQ After installation it will create a group and user. Some middleware technologies are Tibco, SAP XI. MQ series deals with two things, they are OBJECTS, SERVICES. In OBJECTS we have • QUEUES • CHANNELS • PROCESS • AUTHENTICATION • QUERY MANAGER. In SERVICES we have LISTENERS. Objects: – objects are used to handle the transactions with the help of services. QUEUE MANAGER maintains all the objects and services. QUEUE: – it is a database structure

IBM Websphere MQ Reason code list / mq reason codes / websphere mq error codes / mq error messages

Reason code list ================= The following is a list of reason codes, in numeric order, providing detailed information to help you understand them, including: * An explanation of the circumstances that have caused the code to be raised * The associated completion code * Suggested programmer actions in response to the code * 0 (0000) (RC0): MQRC_NONE * 900 (0384) (RC900): MQRC_APPL_FIRST * 999 (03E7) (RC999): MQRC_APPL_LAST * 2001 (07D1) (RC2001): MQRC_ALIAS_BASE_Q_TYPE_ERROR * 2002 (07D2) (RC2002): MQRC_ALREADY_CONNECTED * 2003 (07D3) (RC2003): MQRC_BACKED_OUT * 2004 (07D4) (RC2004): MQRC_BUFFER_ERROR * 2005 (07D5) (RC2005): MQRC_BUFFER_LENGTH_ERROR * 2006 (07D6) (RC2006): MQRC_CHAR_ATTR_LENGTH_ERROR * 2007 (07D7) (RC2007): MQRC_CHAR_ATTRS_ERROR * 2008 (07D8) (RC2008): MQRC_CHAR_ATTRS_TOO_SHORT * 2009 (07D9) (RC2009): MQRC_CONNECTION_BROKEN * 2010 (07DA) (RC2010): MQRC_DATA_LENGTH_ERROR * 2011 (07DB) (RC2011): MQRC_DYNAMIC_Q_NAME_ERROR * 2012 (07DC) (RC201

IBM WebSphere MQ – Common install/uninstall issues for MQ Version on Windows - Middleware News

Creating a log file when you install or uninstall WebSphere MQ WebSphere MQ for Windows is installed using the Microsoft Installer (MSI). If you install the MQ server or client through launchpad , MQPARMS or setup.exe , then a log file is automatically generated in %temp% during installation. Alternatively you can supply parameters on the installation MSI command msiexec to generate a log file, or enable MSI logging system-wide (which generates MSI logs for all install and uninstall operations). If you uninstall through the Windows Add/Remove programs option, no log file is generated. You should either uninstall from the MSI command line and supply parameters to generate a log file, or enable MSI logging system-wide (which generates MSI logs for all install and uninstall operations). For details on how to enable MSI logging, see the following article in the WebSphere MQ product documentation: Advanced installation using msiexec For details on how to enable system-w