MQ

MQ

Join this online group to communicate across IBM product users and experts by sharing advice and best practices with peers and staying up to date regarding product enhancements.

 View Only

  • 1.  ('MQCC_FAILED') reason '2161' ('MQRC_Q_MGR_QUIESCING')

    Posted Mon August 26, 2019 05:35 AM
    Hello,
    I am facing the following situation and I am not sure if it worked correctly or not from the mainframe MQ manager perspective.
    0. The customer Java application acts in POST/PICK mode.
    1. The message was posted to the shared local queue.
    2. A Listener of that MQ (which is the same application), picked the message up for processing.
    3. Error message appeared in the application log:

    Message : com.ibm.mq.MQException: JMSCMQ0001: IBM MQ call failed with compcode '2' ('MQCC_FAILED') reason '2161' ('MQRC_Q_MGR_QUIESCING').
    4. After the application was reconnect to the Queue Sharing Group the same message was picked up and processed again.
    It seems that unfinished MQGET was rolled back on the mainframe MQ manager side but completed on the application side.
    Question(s):
    a) Is this behavior correct?
    b) Why "STOP QMGR MODE(QUIESCE)" did not allow to complete the transaction on both sides?
    c) What exactly is expected to be done by the application in case of above mentioned fail happenning?
    Thank you very much for your statement(s)!
    Best regards,
    Radek



    ------------------------------
    Radek Vanek
    IT Specialist for zSeries IBM MQ, DB2 & DBA
    IBM Certified Specialist & Database Administrator
    IBM Client Innovation Centre Brno Czech Republic
    Email: Radek_Vanek@cz.ibm.com
    ------------------------------


  • 2.  RE: ('MQCC_FAILED') reason '2161' ('MQRC_Q_MGR_QUIESCING')

    Posted Tue August 27, 2019 09:59 AM
    While this is a very specific use case, you may find that tools like Nastel Navigator and Nastel Autopilot may be helpful in helping you manage your MQ queue managers and queues more effectively. 

    I'd suggest you have a look at the free license of Nastel Navigator to get a perspective on how this cam simplify your whole MQ management.

    https://www.nastel.world/nastel-navigator-for-mq-free-version

    ------------------------------
    David Liff
    ------------------------------

    Original Message


  • 3.  RE: ('MQCC_FAILED') reason '2161' ('MQRC_Q_MGR_QUIESCING')

    Posted Tue August 27, 2019 06:54 PM
      Hi Radek,

    The application is telling MQ through an option (MQGMO_Options) that is will accept a failure of the MQGET if the queue manager is quiescing. This is generally considered good behaviour for an application to use, because otherwise an application can prevent timely shutdown of a queue manager (potentially forever).

    From the perspective of the queue manager, the MQGET call didn't really fail, and the message would not have rolled back onto the queue. I would expect that the backout count on the message would still be 0. The queue manager refused the request from the application, and responded with a reason code that explained why.

    The correct application response would be to roll back any work that may need to be done again after the application restarts and it picks up the message. That might mean that nothing has to be done, or the application might have to record it's state somewhere, or reverse something. It would depend on exactly how the application works.

    But, since the message was still present on the queue after the queue manager restart, your application must either be performing the MQPUT outside of syncpoint, or after the MQGET failure response, the application is terminating with a clean shutdown code, hopefully after closing all the MQ handles.

    If the message was MQPUT inside a unit of work with the QM, and should be rolled back when the MQGET fails, then your application would either have to code a MQBACK, or would have to arrange to crash with a failure that the MQClient code could recognise and the backout of the MQPUT could be actioned by the QM.

    If you want your application to complete even if the queue manager is quiescing, you should not code the FAIL IF QUIESCING option, but as I said, that can lead to extended delays in queue manager shutdown, and is generally considered to be poor programming practice.

    If your application will ensure that any delay caused will be short, then not using FAIL IF QUIESCING might be an acceptable solution. For this to be true, the application should not be performing work which can cause significant delay while MQ handles are active, and it should not use MQGET with wait and long wait intervals.

    Regards,

    Neil

    Neil


    -- 
    Neil Casey 
    Senior Consultant | Syntegrity Solutions

    Syntegrity Solutions Pty Ltd | Level 17 | 570 Bourke St | Melbourne | VIC 3000
    Analyse  >>  Integrate  >>  Secure  >>  Educate

    IBM Cloud Private - Foundation TechnologyIBM Cloud Private Infrastructure and ArchitectureIBM Cloud Private Installation and Configuration






    Original Message


  • 4.  RE: ('MQCC_FAILED') reason '2161' ('MQRC_Q_MGR_QUIESCING')

    Posted Tue August 27, 2019 10:31 PM
    a) This behavior is correct and as expected
    b) The queue manager gave you a return code showing you why the transaction failed.
    c) The application is expected to roll back the current transaction
    4) this is expected behavior.

    Enjoy
    F.J.



    Radek wrote
    https://community.ibm.com/community/user/network/members/profile?UserKey=fa67e78c-df5b-4c5e-9628-d4eea826140a. Click or tap to follow the link.">
    Aug 26, 2019 5:35 AM
    https://community.ibm.com/community/user/network/members/profile?UserKey=fa67e78c-df5b-4c5e-9628-d4eea826140a. Click or tap to follow the link.">Radek Vanek
    Hello,
    I am facing the following situation and I am not sure if it worked correctly or not from the mainframe MQ manager perspective.
    0. The customer Java application acts in POST/PICK mode.
    1. The message was posted to the shared local queue.
    2. A Listener of that MQ (which is the same application), picked the message up for processing.
    3. Error message appeared in the application log:

    Message : com.ibm.mq.MQException: JMSCMQ0001: IBM MQ call failed with compcode '2' ('MQCC_FAILED') reason '2161' ('MQRC_Q_MGR_QUIESCING').
    4. After the application was reconnect to the Queue Sharing Group the same message was picked up and processed again.
    It seems that unfinished MQGET was rolled back on the mainframe MQ manager side but completed on the application side.
    Question(s):
    a) Is this behavior correct?
    b) Why "STOP QMGR MODE(QUIESCE)" did not allow to complete the transaction on both sides?
    c) What exactly is expected to be done by the application in case of above mentioned fail happenning?
    Thank you very much for your statement(s)!
    Best regards,
    Radek




    Original Message


Related Content