MQ

 View Only

  • 1.  Temporary dynamic queue

    Posted Wed February 01, 2023 04:56 PM
    I want to create a temporary dynamic reply queue modeled after SYSTEM.COMMAND.REPLY.MODEL

    I see MQQDT_TEMPORARY_DYNAMIC EQU 3  in  CMQA. However I do not see any field documented  clearly that I can set to in CMQODA.

    Is there any way we can make sure the temporary queue that has been modeled after is defined as "Temporary Dynamic Queue"  regardless of the model? 

    regards
    deb

    ------------------------------
    Debabrata Ghosh
    ------------------------------


  • 2.  RE: Temporary dynamic queue

    IBM Champion
    Posted Wed February 01, 2023 07:35 PM

    Hi Deb,

    Unfortunately no. If you want to have a Temporary Dynamic Queue you must ensure you are using a MODEL Queue that is defined as such. There is no way in the MQOPEN call to request this.

    Cheers,
    Morag



    ------------------------------
    Morag Hughson
    MQ Technical Education Specialist
    MQGem Software Limited
    Website: https://www.mqgem.com
    ------------------------------

    Original Message


  • 3.  RE: Temporary dynamic queue

    Posted Wed February 01, 2023 10:23 PM
    thank you. May be we should. 

    regards,
    deb

    ------------------------------
    Debabrata Ghosh
    ------------------------------

    Original Message


  • 4.  RE: Temporary dynamic queue

    Posted Thu February 29, 2024 10:24 AM

    Hi Moragh

     Do you know if there is any limitation using temp dynamic queues on Z/0S Queue sharing group .  One of our applications  connecting to specific Queue manager saying that if they connect to a QSG they are not getting the responses sometimes as you know that if an application sends a request message  from one queue manager it will wait for the response on the same queue manager as Temp dynamic  queue creates on the same queue manager.  In this case there won't be any HA for applications as they always connects to a single specific queue manager instead  of Queue sharing group.

    Best Regards

    Chaitanya.K



    ------------------------------
    Chaitanya kondragunta
    ------------------------------

    Original Message


  • 5.  RE: Temporary dynamic queue

    IBM Champion
    Posted Mon March 04, 2024 10:59 PM

    Hi Chaitanya,

    If I understand your question correctly, you're concerned about a request/reply application that connects to a QSG, makes a dynamic queue for the reply messages, and then later connects again to come and fetch the replies, and that second connect may not go to the same member of the QSG as the first connect, and therefore the QSGDISP(QMGR) dynamic queue that they want to use to fetch their replies is not there because it is on another queue manager. Am I understanding your question correctly? I assume that you must be using permanent dynamic queues for this application if there is the possibility to disconnect and then come back later and the queue still exist. A temporary dynamic queue would be deleted when the application disconnected.

    There is of course the option to have QSGDISP(SHARED) permanent dynamic queues. You do that by using the DEFTYPE(SHAREDYN) option on your QMODEL definition. If you're using permanent dynamic queues, you might be just as well to use standard QLOCAL queues though?

    Alternatively, you could have the application connect to the QSG when it is about to make a request, and connect to the correct queue manager if it is only coming back to retrieve replies.

    Just some thoughts anyway, hope that helps.

    Cheers,
    Morag



    ------------------------------
    Morag Hughson
    MQ Technical Education Specialist
    MQGem Software Limited
    Website: https://www.mqgem.com
    ------------------------------

    Original Message


  • 6.  RE: Temporary dynamic queue

    Posted Tue March 05, 2024 09:25 AM

    Greetings Chaitanya,

    Please do not use dynamic queues for responses from client applications, especially those that connect and disconnect frequently.  The cost of queue creation and destruction can be high, almost as high as the frequent connects and disconnects.  To avoid the problem with clients connecting to different queue managers in the QSG, please use the following technique: 
    1) Make sure the serving program populates the reply message CORRELID  with the  MSGID from the request.
    2) Define a shared queue as the reply queue, indexing it by the CORRELID, that way should there be a disconnect between the request and reply it does not matter which queue manager hosts the get for the reply.
    3) Make sure that the requesting instance keeps the MSGID returned from the request and issues the MQGET for the CORRELID that matches that MSGID (MSGID should be set to null values for the get request). 

    I warn you that the pattern of connect/do one thing/ disconnect from client applications is very expensive in CPU, on any platform.  If this pattern is a once a day occurrence, that's not a problem.  When it becomes a once a second occurrence, even that becomes an issue.  When it becomes once every millisecond it becomes a real problem.  On z/OS, these CPU costs accrue in the CHIN and can dramatically impact costs.  We have observed some customers increasing their MIPS usage by as much as 40% when they implemented this pattern in production.  



    ------------------------------
    Lyn Elkins
    IBM
    Avon, IN
    elkinsc@us.ibm.com
    ------------------------------

    Original Message