none
Biztalk MQSC adapter reasonCode =2034 RRS feed

  • Question

  • We recently had following error on our biztalk box.this is the receive side of the biztalk adapter

    "The adapter "MQSC" raised an error message. Details "Failure encountered while attempting to get message from queue. queue = Queuename, queueManager = queueManager, reasonCode = 2034"."

    Can some one tell me what 2034 code points to and exactly what needs to be done to fix it ? How can I trouble shoot this?

    upon investigating IBM I got following information which I don't understand much and dont know if its directly relevant

    "

    Error description

    • The queue being used is a shared queue. The application is
      receiving an MQRC 2034 MQRC_NO_MSG_UNDER_CURSOR, but only when
      they access large messages.  For example, if they try a 33KB
      message, it works consistently but a message 232KB or larger
      fails with a 2034. The trace shows that the first attempt to
      Get the message, they receive MQRC_TRUNCATED_MSG_FAILED. The
      buffer is increased and then does a Get and receives the
      MQRC_NO_MSG_UNDER_CURSOR.
      

    Local fix

    • 
      

    Problem summary

    • ****************************************************************
      * USERS AFFECTED: All users of WebSphere MQ Version 7 Release  *
      *                 1 Modification 0.                            *
      ****************************************************************
      * PROBLEM DESCRIPTION: Application issues MQGET with           *
      *                      MQGMO_MSG_UNDER_CURSOR to a shared      *
      *                      queue and MQGET fails with              *
      *                      MQRC_NO_MSG_UNDER_CURSOR (2034) when    *
      *                      message is non-persistent > 63K or      *
      *                      persistent of any size.                 *
      ****************************************************************
      * RECOMMENDATION:                                              *
      ****************************************************************
      Application issues a MQGET with MQGMO_BROWSE_xxx + MQGMO_LOCK
      followed by MQGET with MQGMO_MSG_UNDER_CURSOR that fails with
      MQRC_TRUNCATED_MSG_FAILED (2080) and then it re-issues the MQGET
      with MQGMO_MSG_UNDER_CURSOR and the correct buffer size but this
      fails with MQRC_NO_MSG_UNDER_CURSOR (2034).
      

    Problem conclusion

    • The correct browse lock key is now set to enable MQGET with
      MQGMO_MSG_UNDER_CURSOR to find the message that has been
      previously locked.
      100Y
      CSQESYNC

    "


    Wednesday, February 24, 2016 10:51 PM

Answers

  • This issue is not related to BizTalk as clearly mentioned in error description this error occurs

    "when queue access large messages. if they try a 33KB message, it works consistently but a message 232KB or larger fails with a 2034."

    You have to touch base with IBM support team and ask for PTF for this issue.

    Rachit Sikroria (Microsoft Azure MVP)


    Thursday, February 25, 2016 12:52 PM
    Moderator

All replies

  • This issue is not related to BizTalk as clearly mentioned in error description this error occurs

    "when queue access large messages. if they try a 33KB message, it works consistently but a message 232KB or larger fails with a 2034."

    You have to touch base with IBM support team and ask for PTF for this issue.

    Rachit Sikroria (Microsoft Azure MVP)


    Thursday, February 25, 2016 12:52 PM
    Moderator
  • Hi,

    Thank you for posting on MSDN forum.

    As Rachit already addressed this issue is not related to BizTalk Server and I would suggest to connect to IBM tech team for more support. Please refer below IBM support url for more details,

    http://www-01.ibm.com/support/docview.wss?uid=swg1PM63954


    Thanks,

    If my reply is helpful please mark as Answer or vote as Helpful.

    My blog | Twitter | LinkedIn

    This post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

    Sunday, February 28, 2016 6:30 AM