MQ

Hi Bernard,

Q1) What is the actual difference between the MONQ and MONCHL set on OFF or set on MEDIUM regarding the data it is fetching from MQ ?

If you have MONQ(OFF) then you get no data for the following fields in DISPLAY QSTATUS: LGETDATE, LGETTIME, LPUTDATE, LPUTTIME, MSGAGE, and QTIME.

If you have MONCHL(OFF) then you get no data for the following fields in DISPLAY CHSTATUS: COMPRATE, COMPTIME, EXITTIME, NETTIME, XBATCHSZ, XQMSGSA, and XQTIME.

These fields are only enabled when you ask for them because they have one thing in common, they require the collection of (possibly additional) timestamps in order to be produced.

Q2) What is the impact on the performance of the MQ server systems when these params are changed to MEDIUM ?

I believe in the MQ V6.0 timeframe when these fields were introduced, there was some concern that these additional timestamps that I mentioned above might be cause for concern from a performance perspective, and so three levels of collection were introduced, LOW, MEDIUM and HIGH, where each level caused a different number of timestamps to be recorded. In subsequent releases of MQ, MONQ has changed such that all three levels of collection cause the same behaviour.

You may find this blog post of interest since it lists what the sampling rate was once admitted to, now IBM Docs does not show that rate.

All this suggests to me that the impact on performance for queues has reduced to the point where they don't need different sample sizes.

IBM Docs also comments on the impact on performance for channels in the description of the MONCHL attribute, suggesting that MONCHL(MEDIUM) has "limited effect on the performance of the system".

Q3) What is the usual setting for a production MQ environment regarding MONQ and MONCHL ?

I suspect, as with all things MQ, there is no "usual" setting. Firstly it will depend on whether you even want to look at this data. If you don't, since it is not on by default, it will not be enabled unless you have at some point had need to look at it. If you do want to look at the data, then for QSTATUS, there is not longer any query, use any of the enabling values, it's the same. For CHSTATUS I personally would use HIGH so that the numbers reflect all the messages going through the system rather than just some of them, otherwise you may not detect the anomalous behaviours you are looking for. Others may have a different opinion.

In summary, understand what the output will give you and why you want to look at it. If you will get some benefit from it, then consider turning them on. If you won't look at the data, then no need to turn them on.

Cheers,
Morag

Hi Bernard,

Q1) What is the actual difference between the MONQ and MONCHL set on OFF or set on MEDIUM regarding the data it is fetching from MQ ?

If you have MONQ(OFF) then you get no data for the following fields in DISPLAY QSTATUS: LGETDATE, LGETTIME, LPUTDATE, LPUTTIME, MSGAGE, and QTIME.

If you have MONCHL(OFF) then you get no data for the following fields in DISPLAY CHSTATUS: COMPRATE, COMPTIME, EXITTIME, NETTIME, XBATCHSZ, XQMSGSA, and XQTIME.

These fields are only enabled when you ask for them because they have one thing in common, they require the collection of (possibly additional) timestamps in order to be produced.

Q2) What is the impact on the performance of the MQ server systems when these params are changed to MEDIUM ?

I believe in the MQ V6.0 timeframe when these fields were introduced, there was some concern that these additional timestamps that I mentioned above might be cause for concern from a performance perspective, and so three levels of collection were introduced, LOW, MEDIUM and HIGH, where each level caused a different number of timestamps to be recorded. In subsequent releases of MQ, MONQ has changed such that all three levels of collection cause the same behaviour.

You may find this blog post of interest since it lists what the sampling rate was once admitted to, now IBM Docs does not show that rate.

All this suggests to me that the impact on performance for queues has reduced to the point where they don't need different sample sizes.

IBM Docs also comments on the impact on performance for channels in the description of the MONCHL attribute, suggesting that MONCHL(MEDIUM) has "limited effect on the performance of the system".

Q3) What is the usual setting for a production MQ environment regarding MONQ and MONCHL ?

I suspect, as with all things MQ, there is no "usual" setting. Firstly it will depend on whether you even want to look at this data. If you don't, since it is not on by default, it will not be enabled unless you have at some point had need to look at it. If you do want to look at the data, then for QSTATUS, there is not longer any query, use any of the enabling values, it's the same. For CHSTATUS I personally would use HIGH so that the numbers reflect all the messages going through the system rather than just some of them, otherwise you may not detect the anomalous behaviours you are looking for. Others may have a different opinion.

In summary, understand what the output will give you and why you want to look at it. If you will get some benefit from it, then consider turning them on. If you won't look at the data, then no need to turn them on.

Cheers,
Morag

Hi Bernard,

Q1) What is the actual difference between the MONQ and MONCHL set on OFF or set on MEDIUM regarding the data it is fetching from MQ ?

If you have MONQ(OFF) then you get no data for the following fields in DISPLAY QSTATUS: LGETDATE, LGETTIME, LPUTDATE, LPUTTIME, MSGAGE, and QTIME.

If you have MONCHL(OFF) then you get no data for the following fields in DISPLAY CHSTATUS: COMPRATE, COMPTIME, EXITTIME, NETTIME, XBATCHSZ, XQMSGSA, and XQTIME.

These fields are only enabled when you ask for them because they have one thing in common, they require the collection of (possibly additional) timestamps in order to be produced.

Q2) What is the impact on the performance of the MQ server systems when these params are changed to MEDIUM ?

I believe in the MQ V6.0 timeframe when these fields were introduced, there was some concern that these additional timestamps that I mentioned above might be cause for concern from a performance perspective, and so three levels of collection were introduced, LOW, MEDIUM and HIGH, where each level caused a different number of timestamps to be recorded. In subsequent releases of MQ, MONQ has changed such that all three levels of collection cause the same behaviour.

You may find this blog post of interest since it lists what the sampling rate was once admitted to, now IBM Docs does not show that rate.

All this suggests to me that the impact on performance for queues has reduced to the point where they don't need different sample sizes.

IBM Docs also comments on the impact on performance for channels in the description of the MONCHL attribute, suggesting that MONCHL(MEDIUM) has "limited effect on the performance of the system".

Q3) What is the usual setting for a production MQ environment regarding MONQ and MONCHL ?

I suspect, as with all things MQ, there is no "usual" setting. Firstly it will depend on whether you even want to look at this data. If you don't, since it is not on by default, it will not be enabled unless you have at some point had need to look at it. If you do want to look at the data, then for QSTATUS, there is not longer any query, use any of the enabling values, it's the same. For CHSTATUS I personally would use HIGH so that the numbers reflect all the messages going through the system rather than just some of them, otherwise you may not detect the anomalous behaviours you are looking for. Others may have a different opinion.

In summary, understand what the output will give you and why you want to look at it. If you will get some benefit from it, then consider turning them on. If you won't look at the data, then no need to turn them on.

Cheers,
Morag