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.  SYSTEM.INTER.QMGR.PUBS Open input count = 0 but queue depth still grows

    Posted 4 days ago

    Hi, we don't have dedicated MQ administrators any more, I'm part of the sys admin team that inherited support for our MQ 9.3 systems using pub/sub.

    We have a dev environment, plus a pre-prod IBM RDQM cluster, and a prod IBM RDQM cluster.

    On one of the queue managers in the pre-prod cluster, one of the system pub/sub queue has messages filling SYSTEM.INTER.QMGR.PUBS, though curiously, and different to the other environments, open input counts is always = 0 when I look at it, so I don't understand where the messages are coming from, even after clearing the messages they soon start to fill again.

    How do we find where these messages are coming from ?



    ------------------------------
    Gary Spencer
    ------------------------------


  • 2.  RE: SYSTEM.INTER.QMGR.PUBS Open input count = 0 but queue depth still grows

    Posted 4 days ago

    The only queue that contains messages put by applications is SYSTEM.INTER.QMGR.PUBS. MAXDEPTH is set to its maximum value for this queue to allow temporary build up of published messages during outages or times of excessive load. If the queue manager is running on a system where that depth of queue could not be contained, this should be adjusted. as per the documentation.

    You can use the MQ Sample browse program. It will show the PUT application. 

    If MQ Console is enabled, it helps provide details.



    ------------------------------
    om prakash
    Architect
    NorthwesternMutual
    Milwaukee
    ------------------------------



  • 3.  RE: SYSTEM.INTER.QMGR.PUBS Open input count = 0 but queue depth still grows

    Posted 4 days ago

    Hi om prakash,

    thanks, we weren't aware of the sample browser program, that has helped identify where the messages are coming from.

    We had noticed the MAXDEPTH had been changed from the default, though for the other environments they are still default, perhaps this change was as part of troubleshooting by the previous MQ Admins, but alas not documented.

    We are not allowed to make changes on a Friday, regardless of environment, so will look to optimise this next week.

    I should have mentioned we are running MQ on Linux, our investigations will continue.

    Thanks,

    Gary



    ------------------------------
    Gary Spencer
    ------------------------------



  • 4.  RE: SYSTEM.INTER.QMGR.PUBS Open input count = 0 but queue depth still grows

    Posted yesterday

    Just to add to this (for others in the future). If the connection that is putting the messages is intermittent then it would be hard to capture the exact instant the messages were increasing using e.g. explorer or mqsc commands. Activity trace would be the way to go if identifying the put application by looking at the message wasn't enough.

    In the case of SYSTEM.INTER.QMGR.PUBS this is a local queue which holds messages that have come from a remote QM - so it's a little bit more nasty than usual !

    regards,

    John.



    ------------------------------
    John Hawkins
    Integration Consultant
    ------------------------------



  • 5.  RE: SYSTEM.INTER.QMGR.PUBS Open input count = 0 but queue depth still grows

    Posted 7 hours ago

    Did you guys check whether the offending qmgr had pub/sub enabled?



    ------------------------------
    Francois Brandelik
    ------------------------------



  • 6.  RE: SYSTEM.INTER.QMGR.PUBS Open input count = 0 but queue depth still grows

    Posted 6 hours ago

    Hi Francois,

    The QM hosts several queues which are mostly working as expected, but as this queue is unfortunately a system queue it handles messages for all the queues associated with the QM, so it's an arduous task trying to pin down which queue is misbehaving, in answer yes all the queues use pub/sub.

    we've continuing to investigate, I will put our findings here in due course.

    best regards,

    Gary



    ------------------------------
    Gary Spencer
    ------------------------------



  • 7.  RE: SYSTEM.INTER.QMGR.PUBS Open input count = 0 but queue depth still grows

    Posted 6 hours ago

    Hi Gary,

    You misunderstood the question. In the qmgr that has the queue depth, check in the qmgr properties if pub/sub is set to enabled.

    The system queue is supposed to handle pub/sub messages but if pub/sub is not enabled on the queue manager you might not find a consuming process.

    If everything is fine, the next step would be to look into the pub/sub setup (hierarchies, cluster) and proxy subscriptions.

    Hope it helps



    ------------------------------
    Francois Brandelik
    ------------------------------



  • 8.  RE: SYSTEM.INTER.QMGR.PUBS Open input count = 0 but queue depth still grows

    Posted 6 hours ago

    Hi Francois, sorry, yes, pub/sub is enabled for the QM,

    we'll carry on digging, but as MQ admin is not our primary skill, may take some time and lessons to be learnt.

    thanks,



    ------------------------------
    Gary Spencer
    ------------------------------



  • 9.  RE: SYSTEM.INTER.QMGR.PUBS Open input count = 0 but queue depth still grows

    Posted 6 hours ago
    Edited by Francois Brandelik 6 hours ago

    If psmode is set to enabled or compat you should have a system process (amqzmuf0) consuming the messages on that queue.

    in runmqsc check dis qmgr psmode

    Then run dis qs(system.inter.qmgr.pubs) type(handle) all

    If you don't see the conumption process and psmode is not disabled, set it to disabled, then set it to enabled again and check again.



    ------------------------------
    Francois Brandelik
    ------------------------------



  • 10.  RE: SYSTEM.INTER.QMGR.PUBS Open input count = 0 but queue depth still grows

    Posted 5 hours ago

    Hi Francois,

    for those two it's showing:-

    PSMODE(ENABLED)

    APPLTAG(amqzmuf0)

    and as most of the queues are working we don't want to interrupt services unnecessarily, even though we're a little bit lucky this is the non-prod system

    [and ever so grateful it isn't the Prod system exhibiting this behaviour!].

    anyway as I said, investigations continue

    thanks for the good guidance so far,

    best regards,



    ------------------------------
    Gary Spencer
    ------------------------------