Hello, 

I would like to use zHyperWrite functionality for MQ Active Logs operations and to be honest I did not find a way how to prove that it is really in use.

I believe all prerequisites from system and storage points of view are met and the CSQ6LOGP MQ ZPARM parameter ZHYWRITE is se to YES and it seems that the setting is done and all should work fine. But there are two points causing my uncertainty:

a) CSQJ167E message saying "ZHYWRITE(YES) specified but no active logs are zHyperWrite capable" and  

b) CSQJ370I message as a result of DIS LOG command where zHyperWrite=YES is reported in both cases .. when particular active log dataset is capable and is not capable.

I contacted our storage team with the first message but they confirmed to me that involved volumes are enabled for this feature.

Another strange thing is that I activated zHyperWrite for MQ on various LPARs and on some of them the message CSQJ167E appears and on some not even if the active logs datasets format seems to be the same.

Question is - are there any special requirement(s) for the MQ active log datasets format to be capable for zHyperWrite like e.g. must be VSAM extended or must be stripped or with the particular share option .. ? Maybe it could be needed to reallocate the active logs datasets to fit these special requirement but I was not successful to find this kind of information in MQ doc .. 

Would be nice to see if someone has a good experience with zHyperWrite feature activation for MQ. 

Thank you!

Best regards,

Radek Vanek, z/OS MQ System Programmer 

------------------------------
RADEK VANĚK
------------------------------

Hi Radek,

This is unfortunately a bit tricky, because zHyperWrite is largely transparent to MQ. The only awareness that the queue manager has of zHyperWrite is when it initially opens the active log data sets at queue manager start up. We can see whether each data set is enabled or disabled for zHyperWrite, that is all. When we issue a write using zHyperWrite, we can't tell if zHyperWrite was used, or whether the write fell back to a normal MetroMirror/PPRC write. 

The messages you refer to are all based on the feedback the queue manager gets at start up. If the zHyperWrite status of the active logs changes, the queue manager can't tell and has no choice but to use the information it had at start up.

Experience with other customers has shown that sometimes when a MetroMirror session between DASD is established it takes a while to stabilise to the point where zHyperWrite can be used. If the queue manager starts up before this point it will think that the logs aren't enabled for zHyperWrite and you will get messages to this effect. But from a storage team perspective all of the configuration for zHyperWrite is there. It is possible that is what you are seeing. 

What version of MQ are you on? I suggest you take a look at this APAR if at 9.2 or 9.3, or at the docs if at 9.4.0. Basically the original zHyperWrite implementation in MQ would only use zHyperWrite if the log data sets where enabled for zHyperWrite at queue manager start up. If they weren't then zHyperWrite would never be used. Subsequently it became apparent that zHyperWrite is more dynamic than we thought, and can come and go. So in 9.4, and via that APAR, we changed the behaviour so that if ZHYWRITE(YES) is set the queue manager would always try and use zHyperWrite when writing to the log, regardless of whether the log data sets had zHyperWrite enabled at start up or not.

Hopefully that makes sense!

To answer your questions:

1) This page describes the requirements for zHyperWrite with MQ. Bar ZHYWRITE(YES), everything else is done at the volume level, and there are no MQ specific requirements on those volumes or data sets

2) The only way you can prove that zHyperWrite is being used is by observing the performance benefits that it brings. If you turn on MQ's SMF 115 data, i.e. stats, you should be able to see some of the time based QJST values reduce. If you run a workload through a queue manager and toggle the value of ZHYWRITE from NO to YES then you should see QJSTIOTOTIO (total I/O duration) reduce with ZHYWRITE(YES). I have seen significant reductions in QJSTIOTOTIO at most customers

Unfortunately there is no other way to observe the benefits from zHyperWrite. Its an area I would love to improve, but MQ is dependent on getting more feedback from the disk interfaces (Media Manager). I have an idea raised against Media Manager, please vote on it!

I know lots of customers that have exploited zHyperWrite and really benefited from it, so please persevere. Also zHyperWrite is a prereq for the zHyperLink support we added in 9.4.

Let me know if you have further questions.

Regards, Matt.

------------------------------
Matt Leming
STSM, IBM MQ for z/OS
Email: lemingma@uk.ibm.com
------------------------------

Hello Matt, 

many thanks for your reply and appreciated detailed explanation. It confirms to me that only way - at the moment - to prove the usage of zHyperWrite is to compare the SMF 115 records before and after the function enabling. That's OK. 

To reply you question - we are running version 9.4 .. and with this version a little confusion came (in my opinion) in message CSQJ370I .. zHyperWrite information is always shown based on ZHYWRITE system parameter value only without reflection if the volume (or storage at all) is capable or not .. but yes, now I understood that it was the intention to always prioritize and try to use this kind of write request.

Finally, I voted for your idea .. I fully agree with it and it could be nice to have a possibility to see the real usage status.

Thanks again and have a nice day!

Best regards,

Radek

------------------------------
RADEK VANĚK
------------------------------

Original Message:
Sent: Wed August 20, 2025 07:56 AM
From: MATTHEW LEMING
Subject: zHyperWrite usage in IBM MQ 9.4 for z/OS

Hi Radek,

This is unfortunately a bit tricky, because zHyperWrite is largely transparent to MQ. The only awareness that the queue manager has of zHyperWrite is when it initially opens the active log data sets at queue manager start up. We can see whether each data set is enabled or disabled for zHyperWrite, that is all. When we issue a write using zHyperWrite, we can't tell if zHyperWrite was used, or whether the write fell back to a normal MetroMirror/PPRC write. 

The messages you refer to are all based on the feedback the queue manager gets at start up. If the zHyperWrite status of the active logs changes, the queue manager can't tell and has no choice but to use the information it had at start up.

Experience with other customers has shown that sometimes when a MetroMirror session between DASD is established it takes a while to stabilise to the point where zHyperWrite can be used. If the queue manager starts up before this point it will think that the logs aren't enabled for zHyperWrite and you will get messages to this effect. But from a storage team perspective all of the configuration for zHyperWrite is there. It is possible that is what you are seeing. 

What version of MQ are you on? I suggest you take a look at this APAR if at 9.2 or 9.3, or at the docs if at 9.4.0. Basically the original zHyperWrite implementation in MQ would only use zHyperWrite if the log data sets where enabled for zHyperWrite at queue manager start up. If they weren't then zHyperWrite would never be used. Subsequently it became apparent that zHyperWrite is more dynamic than we thought, and can come and go. So in 9.4, and via that APAR, we changed the behaviour so that if ZHYWRITE(YES) is set the queue manager would always try and use zHyperWrite when writing to the log, regardless of whether the log data sets had zHyperWrite enabled at start up or not.

Hopefully that makes sense!

To answer your questions:

1) This page describes the requirements for zHyperWrite with MQ. Bar ZHYWRITE(YES), everything else is done at the volume level, and there are no MQ specific requirements on those volumes or data sets

2) The only way you can prove that zHyperWrite is being used is by observing the performance benefits that it brings. If you turn on MQ's SMF 115 data, i.e. stats, you should be able to see some of the time based QJST values reduce. If you run a workload through a queue manager and toggle the value of ZHYWRITE from NO to YES then you should see QJSTIOTOTIO (total I/O duration) reduce with ZHYWRITE(YES). I have seen significant reductions in QJSTIOTOTIO at most customers

Unfortunately there is no other way to observe the benefits from zHyperWrite. Its an area I would love to improve, but MQ is dependent on getting more feedback from the disk interfaces (Media Manager). I have an idea raised against Media Manager, please vote on it!

I know lots of customers that have exploited zHyperWrite and really benefited from it, so please persevere. Also zHyperWrite is a prereq for the zHyperLink support we added in 9.4.

Let me know if you have further questions.

Regards, Matt.

------------------------------
Matt Leming
STSM, IBM MQ for z/OS
Email: lemingma@uk.ibm.com
------------------------------

Original Message:
Sent: 8/21/2025 8:31:00 AM
From: RADEK VANĚK
Subject: RE: zHyperWrite usage in IBM MQ 9.4 for z/OS

Hello Matt, 

many thanks for your reply and appreciated detailed explanation. It confirms to me that only way - at the moment - to prove the usage of zHyperWrite is to compare the SMF 115 records before and after the function enabling. That's OK. 

To reply you question - we are running version 9.4 .. and with this version a little confusion came (in my opinion) in message CSQJ370I .. zHyperWrite information is always shown based on ZHYWRITE system parameter value only without reflection if the volume (or storage at all) is capable or not .. but yes, now I understood that it was the intention to always prioritize and try to use this kind of write request.

Finally, I voted for your idea .. I fully agree with it and it could be nice to have a possibility to see the real usage status.

Thanks again and have a nice day!

Best regards,

Radek

------------------------------
RADEK VANĚK
------------------------------