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
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
Post a Comment