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
Back to discussions
Expand all | Collapse all

Queue status LGETTIME ?

  • 1.  Queue status LGETTIME ?

    Posted Wed July 02, 2025 11:26 AM
    Edited by Joao Ramires Wed July 02, 2025 12:07 PM

    Hello all!

    I've a script running in a loop doing a display qstatus for queue "QX"  each minute. Messages are not being consumed, but I see the LGETIME being updated, and the update shows it each minute, the loop delay, so I guess a DISPLAY QSTATUS, counts for the LGETTIME. If this is correct how can I find the LGETTIME the application reading these messages did a GET? 

    Thanks! 

    This is a sample output, when CURDEPTH not 0 

    202507021604;QUEUE(QX);TYPE(QUEUE);CURDEPTH(4897);IPPROCS(36);LGETTIME(16.04.09);MSGAGE(536);QTIME(528303854,534995245);
    202507021605;QUEUE(QX);TYPE(QUEUE);CURDEPTH(4949);IPPROCS(36);LGETTIME(16.05.00);MSGAGE(561);QTIME(539412826,550112888);
    202507021606;QUEUE(QX);TYPE(QUEUE);CURDEPTH(5130);IPPROCS(36);LGETTIME(16.06.08);MSGAGE(591);QTIME(581428340,588563298);
    202507021607;QUEUE(QX);TYPE(QUEUE);CURDEPTH(5263);IPPROCS(36);LGETTIME(16.07.10);MSGAGE(583);QTIME(578282501,582036260);
    202507021608;QUEUE(QX);TYPE(QUEUE);CURDEPTH(5395);IPPROCS(36);LGETTIME(16.08.10);MSGAGE(597);QTIME(586453032,582246318);
    202507021609;QUEUE(QX);TYPE(QUEUE);CURDEPTH(5562);IPPROCS(36);LGETTIME(16.09.09);MSGAGE(603);QTIME(596517880,601214980);
    202507021610;QUEUE(QX);TYPE(QUEUE);CURDEPTH(5700);IPPROCS(36);LGETTIME(16.10.09);MSGAGE(633);QTIME(624763472,628459100);
    202507021611;QUEUE(QX);TYPE(QUEUE);CURDEPTH(5854);IPPROCS(36);LGETTIME(16.11.09);MSGAGE(637);QTIME(631450408,635854548);
    202507021612;QUEUE(QX);TYPE(QUEUE);CURDEPTH(6091);IPPROCS(36);LGETTIME(16.12.10);MSGAGE(668);QTIME(658423937,666925301);
    202507021613;QUEUE(QX);TYPE(QUEUE);CURDEPTH(6223);IPPROCS(36);LGETTIME(16.13.10);MSGAGE(657);QTIME(658327044,656224997);
    202507021614;QUEUE(QX);TYPE(QUEUE);CURDEPTH(6135);IPPROCS(36);LGETTIME(16.14.10);MSGAGE(682);QTIME(672834453,679248596);
    202507021615;QUEUE(QX);TYPE(QUEUE);CURDEPTH(5647);IPPROCS(36);LGETTIME(16.15.10);MSGAGE(665);QTIME(673735372,664562076);
    202507021616;QUEUE(QX);TYPE(QUEUE);CURDEPTH(5262);IPPROCS(36);LGETTIME(16.16.10);MSGAGE(688);QTIME(683472233,686400242);
    202507021617;QUEUE(QX);TYPE(QUEUE);CURDEPTH(4807);IPPROCS(36);LGETTIME(16.17.09);MSGAGE(693);QTIME(682311621,689324008);
    202507021618;QUEUE(QX);TYPE(QUEUE);CURDEPTH(4420);IPPROCS(36);LGETTIME(16.18.10);MSGAGE(694);QTIME(688357808,692888760);
    202507021619;QUEUE(QX);TYPE(QUEUE);CURDEPTH(3964);IPPROCS(36);LGETTIME(16.19.10);MSGAGE(727);QTIME(720857505,726626315);

    when the queue is empty the LGETTIME shows the time last GET was, and when CURDEPTH = 0 

    202507021631;QUEUE(QX);TYPE(QUEUE);CURDEPTH(0);IPPROCS(36);LGETTIME(16.28.14);MSGAGE(0);QTIME(834251469,586289360);
    202507021631;QUEUE(QX);TYPE(QUEUE);CURDEPTH(0);IPPROCS(36);LGETTIME(16.28.14);MSGAGE(0);QTIME(834251469,586289360);
    202507021631;QUEUE(QX);TYPE(QUEUE);CURDEPTH(0);IPPROCS(36);LGETTIME(16.28.14);MSGAGE(0);QTIME(834251469,586289360);
    202507021631;QUEUE(QX);TYPE(QUEUE);CURDEPTH(0);IPPROCS(36);LGETTIME(16.28.14);MSGAGE(0);QTIME(834251469,586289360);
    202507021631;QUEUE(QX);TYPE(QUEUE);CURDEPTH(0);IPPROCS(36);LGETTIME(16.28.14);MSGAGE(0);QTIME(834251469,586289360);
    202507021632;QUEUE(QX);TYPE(QUEUE);CURDEPTH(0);IPPROCS(36);LGETTIME(16.28.14);MSGAGE(0);QTIME(834251469,586289360)

    ------------------------------
    Joao Ramires
    ------------------------------



  • 2.  RE: Queue status LGETTIME ?

    Posted Wed July 02, 2025 07:49 PM

    Issuing a DISPLAY QSTATUS command DOES NOT cause an update to LGETTIME. Nor does doing a browse of a queue. Only a destructive get will cause an update to LGETTIME.

    Also, while MSGAGE increases while there is no activity on a queue, QTIME is only updated once a message is destructively removed from a queue, because only at that point can the queue manager calculate how long it stayed on the queue. So the fact that your QTIME values are changing shows that at least one of your 36 applications, that have the queue open for input, is definitely getting messages, and that will be the application that is also resulting in the changes seen to the LGETTIME.

    You say that "messages are not being consumed" but I am not sure what metric you are using to determine this fact. Perhaps you can give us some more details on that?

    I can see just by looking at the CURDEPTH values that you have shown that messages clearly are getting consumed. To begin with the queue depth is increasing, but then about half-way through your example status, we can see that the depth starts to decrease. So it would appear that messages are being consumed but just simply not quite as fast as messages are being put onto the queue in the first half of your status output examples.

    So, to answer your direct question, "how can I find the LGETTIME the application reading these messages did a GET" - the answer is to view the LGETTIME attribute just exactly as you are doing.

    You might find it useful to look into the RESET QSTATS command to see exactly how many messages go onto the queue, and come off of the queue in each interval between issuing one instance of the RESET command and the next instance.

    Cheers,
    Morag



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

    Original Message


  • 3.  RE: Queue status LGETTIME ?

    Posted Thu July 03, 2025 03:03 AM

    Further to Morag's response, and specifically with respect to the mention of RESET QSTATS, you might find it easier to get statistics via the more modern system topics rather than the queue, especially if you are using MQ on distributed rather than zOS.

    RESET QSTATS on zOS can be implemented using a command, but on distributed a PCF message issued by a program is needed if I recall correctly.

    Instead, simple queue statistics can be obtained from the system topics using sample program amqsrua. You can run 2 instances in two terminal windows. One would request GET data for the queue, and the other would request PUT and PUT1 data.

    With this data you can positively identify how many messages have been put to the queue or consumed, without trying to interpret from periodic snapshots of the queue depth.

    The output will show 10 second periods with the numbers of GET and PUTs of messages to the queue in the time interval. amqsrua will prompt you to supply options if they are not provided on the command line, but if you have worked out the options, you can just include them.

    For example, the following command would show the GET message statistics at 10 seconds intervals for queue called CASEY on a queue manager named NEIL.

    /opt/mqm/samp/bin/amqsrua -m NEIL -c STATQ -o CASEY -t GET

    The output looks like:

    Publication received PutDate:20250703 PutTime:06562021 Interval:10 minutes,49.009 seconds
    CASEY                                            MQGET count 0
    CASEY                                            MQGET byte count 0
    CASEY                                            destructive MQGET non-persistent message count 0
    CASEY                                            destructive MQGET persistent message count 0
    CASEY                                            rolled back MQGET count 0
    CASEY                                            destructive MQGET non-persistent byte count 0
    CASEY                                            destructive MQGET persistent byte count 0
    CASEY                                            MQGET browse non-persistent message count 0
    CASEY                                            MQGET browse persistent message count 0
    CASEY                                            MQGET browse non-persistent byte count 0
    CASEY                                            MQGET browse persistent byte count 0
    CASEY                                            destructive MQGET fails 0
    CASEY                                            destructive MQGET fails with MQRC_NO_MSG_AVAILABLE 0
    CASEY                                            destructive MQGET fails with MQRC_TRUNCATED_MSG_FAILED 0
    CASEY                                            MQGET browse fails 0
    CASEY                                            MQGET browse fails with MQRC_NO_MSG_AVAILABLE 0
    CASEY                                            MQGET browse fails with MQRC_TRUNCATED_MSG_FAILED 0

    If you leave the application running, it will emit further information every 10 seconds showing the activity during that interval...

    For example:

    Publication received PutDate:20250703 PutTime:06593779 Interval:10.000 seconds
    CASEY                                            MQGET count 14 1/sec
    CASEY                                            MQGET byte count 42 4/sec
    CASEY                                            destructive MQGET non-persistent message count 14 1/sec
    CASEY                                            destructive MQGET persistent message count 0
    CASEY                                            rolled back MQGET count 0
    CASEY                                            destructive MQGET non-persistent byte count 42 4/sec
    CASEY                                            destructive MQGET persistent byte count 0
    CASEY                                            MQGET browse non-persistent message count 0
    CASEY                                            MQGET browse persistent message count 0
    CASEY                                            MQGET browse non-persistent byte count 0
    CASEY                                            MQGET browse persistent byte count 0
    CASEY                                            destructive MQGET fails 0
    CASEY                                            destructive MQGET fails with MQRC_NO_MSG_AVAILABLE 0
    CASEY                                            destructive MQGET fails with MQRC_TRUNCATED_MSG_FAILED 0
    CASEY                                            MQGET browse fails 0
    CASEY                                            MQGET browse fails with MQRC_NO_MSG_AVAILABLE 0
    CASEY                                            MQGET browse fails with MQRC_TRUNCATED_MSG_FAILED 0

    If you want to have a single program collect more than just a single set of data (like both get and put) you can write your own application to subscribe to the statistics queues.

    Regards,



    ------------------------------
    Neil Casey
    Senior Consultant
    Syntegrity Solutions
    Melbourne, Victoria
    IBM Champion (Cloud) 2019-22
    ------------------------------

    Original Message


  • 4.  RE: Queue status LGETTIME ?

    Posted Thu July 03, 2025 09:42 AM

    Neil's suggestion to use amqsrua is a good one and (though it's not well documented) you can supply multiple arguments to amqsrua to enable both PUT and GET stats from the same command –

     

    e.g.

    /opt/mqm/samp/bin/amqsrua -m NEIL -c STATQ -t PUT -o CASEY -c STATQ -t GET -o CASEY

     

    However, comparing the data in amqsrua intervals is not particularly easy so it would also be worth considering the performance tool (mqperfck), available in the latest Fix Packs for 9.2, 9.3, and 9.4 LTS (plus 9.4.2 and later CD releases).

     

    mqperfck shows the statistics for each interval side-by-side on the right of the report making it a bit easier to see activity over time.

     

    e.g. Running analysis on the same queue for  6x10 second intervals :

    mqperfck -m NEIL -q CASEY -n 6

    The performance tool produces output like:

     

    Queue: CASEY

    MQPUT and MQPUT1 (CASEY)

    First publication: 13:23:12.278

    Last publication: 13:24:12.285

    Statistic

    Min value

    Max value

    Interval avg

    Raw values

    Interval length

    10000000us

    10001956us

    10000907.83us

    [10000000, 10000232, 10001409, 10000664, 10001186, 10001956]

    lock contention

    2.35%

    20.55%

    7.07%

    [6.27, 4.12, 20.55, 2.35, 4.09, 5.03]

    MQPUT non-persistent message count

    500

    500

    500.00

    [500, 500, 500, 500, 500, 500]

    non-persistent byte count

    2080000

    2080000

    2080000.00

    [2080000, 2080000, 2080000, 2080000, 2080000, 2080000]

    ----------

    MQGET (CASEY)

    First publication: 13:23:12.278

    Last publication: 13:24:12.285

    Statistic

    Min value

    Max value

    Interval avg

    Raw values

    Interval length

    10000000us

    10001956us

    10000907.83us

    [10000000, 10000232, 10001409, 10000664, 10001186, 10001956]

    MQGET browse fails with MQRC_NO_MSG_AVAILABLE

    0

    87

    32.17

    [0, 0, 0, 35, 87, 71]

    MQGET browse fails

    0

    87

    32.17

    [0, 0, 0, 35, 87, 71]

    destructive MQGET fails

    0

    1

    0.17

    [0, 0, 0, 0, 0, 1]

    MQGET browse non-persistent byte count

    0

    5947200

    2761908.00

    [2124000, 4248000, 0, 5947200, 2124000, 2128248]

    MQGET browse non-persistent message count

    0

    1400

    650.17

    [500, 1000, 0, 1400, 500, 501]

    destructive MQGET non-persistent byte count

    0

    5947200

    2761200.00

    [2124000, 4248000, 0, 5947200, 2124000, 2124000]

    destructive MQGET non-persistent message count

    0

    1400

    650.00

    [500, 1000, 0, 1400, 500, 500]

    MQGET byte count

    0

    11894400

    5523108.00

    [4248000, 8496000, 0, 11894400, 4248000, 4252248]

    MQGET count

    0

    2800

    1300.17

    [1000, 2000, 0, 2800, 1000, 1001]

     

    General queue metrics (CASEY)

    First publication: 13:23:12.279

    Last publication: 13:24:12.285

    Statistic

    Min value

    Max value

    Interval avg

    Raw values

    Interval length

    10000000us

    10001956us

    10000907.83us

    [10000000, 10000232, 10001409, 10000664, 10001186, 10001956]

    open input count

    0

    1

    0.50

    [0, 0, 0, 1, 1, 1]

    open output count

    50

    50

    50.00

    [50, 50, 50, 50, 50, 50]

    open browse count

    0

    1

    0.50

    [0, 0, 0, 1, 1, 1]

    Queue depth

    0

    900

    366.67

    [900, 400, 900, 0, 0, 0]

    average queue time

    0us

    17268688us

    7278240.17us

    [17268688, 17183347, 0, 9215225, 974, 1207]

     

     

    Regards

    Mark

    Unless otherwise stated above:

    IBM United Kingdom Limited
    Registered in England and Wales with number 741598
    Registered office: Building C, IBM Hursley Office, Hursley Park Road, Winchester, Hampshire SO21 2JN



    Original Message


  • 5.  RE: Queue status LGETTIME ?

    Posted Thu July 03, 2025 10:34 AM

    Thanks Mark

    I've MQ 9.3.1 AIX, don't find mqperfck in it. I tried it on Windows platform with MQ 9.4. It produces html format, can it outputs another format? 



    ------------------------------
    Joao Ramires
    ------------------------------

    Original Message


  • 6.  RE: Queue status LGETTIME ?

    Posted Thu July 03, 2025 04:37 PM

    Hi Joao

     

    mqperfck is relatively new (it first shipped in 9.4.2) so it is not available in 9.4.1 or older CD releases. However we did make it available in the last round of 9.2, 93, and 9.4 Fix Packs for distributed platforms... see Known issue DT429852 / APAR IT47564 for details. 

     

    The first goal of mqperfck was to produce a human readable report, so HTML is the only output format available, but if you'd like something more machine-readable then we'd be interested in your ideas.

     

    Hope that helps

    Mark

    Unless otherwise stated above:

    IBM United Kingdom Limited
    Registered in England and Wales with number 741598
    Registered office: Building C, IBM Hursley Office, Hursley Park Road, Winchester, Hampshire SO21 2JN



    Original Message


  • 7.  RE: Queue status LGETTIME ?

    Posted Thu July 03, 2025 06:13 PM

    Thanks Mark,

    I've been using amqsrua for quite a while, and had no idea that multiple parameters could be requested together. I hadn't picked up on mqperfck yet either, so that will definitely be my next tool to investigate.

    Regards,



    ------------------------------
    Neil Casey
    Senior Consultant
    Syntegrity Solutions
    Melbourne, Victoria
    IBM Champion (Cloud) 2019-22
    ------------------------------

    Original Message


  • 8.  RE: Queue status LGETTIME ?

    Posted Fri July 04, 2025 12:23 AM

    Neil Casey notes that "RESET QSTATS on zOS can be implemented using a command, but on distributed a PCF message issued by a program is needed if I recall correctly."

    Requiring a PCF program does not mean you are unable to use it in a script however. While the obvious PCF programs are GUIs like MQ Explorer and MO71, I should mention here that MQSCX has implemented the PCF command for RESET QSTATS allowing you to use it in MQSCX scripts for this sort of purpose. It came about as a result of a conversation similar to the one on here, but over on the mqseries.net forum and there are some good discussions about the pro and cons of RESET QSTATS in the thread on there (press next to ensure you read page two of the thread when you get to the bottom of the page).

    Obviously this is a vendor program, from MQGem Software, but you appear to be familiar with the Q program which is another one from our stable, so perhaps that is not a problem.

    Cheers,
    Morag



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

    Original Message


  • 9.  RE: Queue status LGETTIME ?

    Posted Thu July 03, 2025 03:23 AM
    The last get time is the time of the last get - as you will see when the queue is empty.

    It looks like there are two activities 
    - messages being read from the queue (at around  400 a minute < about 6-10 a second) ( see the last few lines of data when the queue depth is decreasing
    - messages being put to the queue at put rate + 100 a second, when the queue depth is increasing.

    When the putting activity ends, the queue is drained as we can see from the curdepth.

    Your getting rate seems low - you might need to see what else it is doing - such as database work.

    You might consider more than one getting task (if your application can handle that)- or find out why your getting application is slow.

    Colin





    Original Message


  • 10.  RE: Queue status LGETTIME ?

    Posted Thu July 03, 2025 07:32 AM

    Thank you all for the answers!
    As Morag says, using RESET QSTAT it's a good suggestion 

    Neil: I used amqsrua in some other situations, the output it's not very friendly, one advantage of my script it produces an easily format that I can import in a spreadsheet .

    Colin: yes the app is slow consuming messages, it's a WebSphere app, sometimes GC starts and takes long seconds, or it can be coding issues, or db

    One additional note, asking about QTIME to MS Copilot, I have this answer. The HI and LO I don't see them on AIX MQ v9310

    AMQ8450I: Display queue status details.
   QUEUE(YourQueueName)  TYPE(QUEUE)
   QTIME HI(0000000200) LO(0000000005)

    . 



    ------------------------------
    Joao Ramires
    ------------------------------

    Original Message


  • 11.  RE: Queue status LGETTIME ?

    Posted Thu July 03, 2025 09:05 AM

    I don't what MS Copilot is doing there. That is not expected output of QSTATUS. You know already from your own script that QTIME shows in MQSC like this:-

    QTIME(528303854,534995245);

    That looks like something is pulling out the two values and calling then HI and LO, but MQSC doesn't do that. Perhaps it is another tool reformatting the MQSC output?

    Cheers,
    Morag



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

    Original Message


  • 12.  RE: Queue status LGETTIME ?

    Posted Thu July 03, 2025 09:17 AM

    You may find this approach helpful, as well.

    https://community.ibm.com/community/user/blogs/tim-zielke1/2020/11/19/measuring-ibm-mq-distributed-api-response-time-wit



    ------------------------------
    Tim Zielke
    ------------------------------

    Original Message


  • 13.  RE: Queue status LGETTIME ?

    Posted Thu July 03, 2025 09:34 AM
    Edited by Joao Ramires Thu July 03, 2025 09:38 AM

    Thanks Tim , I guess activity trace is to "big" to use in my case, but I learned from your post the existence of amqsblst!

    Looks like an excellent tool for testing purposes. I usually use q program or dmpmqmsg to put/get messages in my tests. 



    ------------------------------
    Joao Ramires
    ------------------------------

    Original Message


  • 14.  RE: Queue status LGETTIME ?

    Posted Thu July 03, 2025 09:42 AM

    I would recommend investing the time in learning the Application Activity Trace. Tracing like strmqtrc would probably be too big/involved, but the Application Activity Trace was designed for the IBM MQ admin to have a tool to better understand/debug IBM MQ applications. I have found it an invaluable tool, myself.



    ------------------------------
    Tim Zielke
    ------------------------------

    Original Message


Related Content